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.
- Receiving Urgent Market Message Push Notifications from Nord Pool - November 1, 2018
- Zen and the Art of Computer Programming - September 2, 2017
- Reading JSON Files to Create Test Versions of REST Clients - April 8, 2017
In my experience i have found that in order to develop a system to behave correctly the understanding of its correctness has to be explained to several actors: development team, architects, clients, users and owners. In order to understand correctness this actors has to reconciliate often in order to validate and verify the product under construction. These conditions claims that we have to have more meetings in order to dissolve complexity and misunderstandings. In order to have time to build the product, efficient meetings has to be provided and asserted for. In that order we facilitate that the project continuously is verified and validated.