Category: Everybody, All Together, From Early On

Estimating user stories may sometimes be useful to predict, for example, what can be included in an upcoming release. If you estimate using hours and days, it usually takes a long time to agree on the estimates. An alternative is to use relative story sizes for the estimates instead of absolute time. This often turns out to be quicker, and at least as reliable as using time estimates.

The traditional way to estimate using relative story sizes is to use story points. This post presents a simplified approach using T-shirt sizes: XS, S, M, L and XL.

When to Use Relative Estimates

The first question to ask is if you should estimate at all. If you see no benefit to the estimates, then don’t produce them. For example, in a short project it is usually more effective to prioritize the user stories and just work as quickly as possible.

If you decide to use estimates, the next question is if you can use relative story size. The approach described here works best in longer projects where the team does not change much over time. Under these conditions, you can use the estimates to measure how much work is actually finished during a sprint, a number called the velocity. The velocity can be used to limit what is included in a sprint, and to predict future releases.

The Estimation Process

It is important not to overspecify the meaning of the different sizes. Just define XS as being something that is very easy and quick, and XL as being something that is close to not fitting into a single sprint. The team will automatically create their own definition of what the sizes mean.

To do the actual estimation of a user story, a variant of planning poker can be used where you can use your hands instead of a deck of cards. Since there are only five sizes available, you can use your fingers to show your estimate, with one finger being XS and five fingers XL. If something is either too small or too large, just show your fist.

So for each user story that you want to estimate, discuss the story internally, and when everyone seems to agree on what the story means, ask the team to simultaneously give their estimates using their hands.

If there are different estimates for a story, the people with the highest and the lowest estimates explain why they think their estimate is correct. The process is repeated until a consensus is reached.

If the team agrees that a story is smaller than XS then it should be included in some other story. If the story is larger than XL, it needs to be broken down into separate stories, perhaps using an epic to group the stories together.

Calculating Velocity

Calculating the velocity of the team is simplified if you have numbers to work with instead of T-shirt sizes. Numbers are also easier to use with a tool like JIRA Agile. Here is a table translating the T-shirt sizes into numerical values:

• XS = 2
• S = 3
• M = 5
• L = 8
• XL = 13

You probably recognize the numbers as part of the Fibonacci sequence. This number sequence is commonly used when estimating with story points, and has the appropriate property of being non-linear. This means that a story that is XL is several times larger than one that is XS.

In a team new to Scrum and relative estimates, you may want to avoid using the numerical values and only use the T-shirt sizes when discussing story size with the team.

Conclusion

If you have problems with estimates and find that the estimation process takes too long, try this simple approach using T-shirt sizes to estimate user story size.

In the book Lean Architecture: for Agile Software Development, the authors James O. Coplien and Gertrud Bjørnvig claim that the secret to Lean is Everybody, all together, from early on. I don’t know enough of the history of Lean to say if that is true, but I do know that the “Lean Secret” works in practice.

The more I work in different projects and with different teams, the more I see that bringing in all the people that will be affected by the project, as early as possible, is a key factor to project success. This is not to say that everybody needs to be working actively on the project on a daily basis, but they should all be kept in the loop.

How do you know which people should be included? Try a short brainstorming session very early in the project with all the stakeholders you have identified so far. You can probably identify a few more people that will be affected in some way by the project. Use your imagination.

The people to include differs from organization to organization, and from project to project, but here is a partial list:

• The product owner and the team members, such as developers and testers, are obvious.
• Architects will want a say in how the system is designed.
• System administrators want to know how the system affects IT operations.
• The support organization may need to learn a bit about the system to be able to answer questions.
• If the system requires training, the people developing the training material need to be informed as soon as possible.
• The sales department may need to know about the system or product being built.
• Last but not least, the users of the system may be interested in what the future brings.

Make a habit of constantly trying to identify new stakeholders. The earlier you can include them, the better, but if you late in the project find new people that should be informed, do all you can to get them up to speed on what the project is doing.

How do you keep all the stakeholders informed of what is going on? One simple way is to invite people to the demos that end each sprint. Not everyone will be able to come to every demo, but keep reminding them of the opportunity. If some people are particularly affected by something being demonstrated, push extra hard for them to attend that particular demo. Including people in mail correspondence is an easy way to keep them informed—just don’t include everyone in every correspondence. You can also try to invite people as observers to the daily stand-up meetings, but these meetings are often a bit too technical for the majority of stakeholders.

Using the Lean Secret effectively is an art that requires practice, but it can make or break a project.