Time Estimation Techniques

Over the years, we’ve been involved in a lot of discussions about how to estimate during sprint planning. If you’re new to Scrum – or even if you’re not – you might find value in these musings.

Story Points. There are some very good reasons to estimate in story points rather than in man-hours. When you work in an Agile environment, everybody pretty much agrees that there is uncertainty to every user story. In order to claim that a requirement will “cost” 8 man-hours, you should first call in a business analyst to flesh out the requirement until it’s 100% unambiguous, and also an architect to design a solution for it. So, to save the customer’s money, you skip the long and detailed planning and just estimate the relative weight of the stories. Then, knowing the real cost of some of them, you can roughly evaluate the others. Remember, you are always guessing – estimation is not an exact science.

Fibonacci Numbers. Since there is no hard relationship between story points (SP) and time, you shouldn’t pretend that you are being precise with your estimates. Let’s say story A is 7 SPs, story B is 8 SPs and story C is 9 SPs. Assuming that story A is rather difficult (it does, after all, take 7 SPs and not just 1), story B is obviously more complex – but is it 14% more complex? or a single story point more complex?? And what can we say about story C? Is it 28% more complex than A or 12.5% more complex than B? What do these numbers even mean if we don’t have a clue how long can story A will actually take to implement?

That is why many people suggest using Fibonacci numbers (1, 2, 3, 5, 8, 13, etc.). Personally we prefer stories smaller than 8 and always insist on splitting the story if the team estimates it at 21 or more. Back to the meaning of SPs: an estimate of 5 tells me that the story is rather complex but understandable and doable, while 21 means that nobody really has a plan what to do and how.

Sprint Backlog. People who are new to Scrum often ask this question: How do you decide which stories can be included in the sprint if story points are not convertible to man-hours? This is our favorite part of the estimation process. In case it’s the first sprint planning with the new team, just ask them whether they feel confident about committing to doing the top N stories from the backlog during the sprint. Arrive at the maximum N – and there, you have your sprint backlog. After the first sprint is finished, add up the SPs of all the stories implemented by the team – this is your baseline for the next sprint. Ask the team if they see any factors that can affect their velocity. If there are any such factors (people leaving or joining the team, lessons learned in the previous sprint, bad weather, soccer world cup being aired on TV next week – everything counts), pick a number F (between zero and infinity) that would reflect these factors. Then take the top M stories that fit the baseline number of SPs multiplied by F. Check yourself: ask the team if they are comfortable with the sprint backlog, and if they think they can do more. After you have completed a number of sprints, you will be able to guess F quite accurately.

Planning Poker. Now that the team understands the background, we can start Sprint Planning. Team members sit together, discuss the user stories, share implementation plans and give their estimates. To be honest, we don’t understand what problem people are trying to solve by bringing cards to the planning session. If you have a leader who is trying to give all the estimates, just buy them an ice cream or something, and ask them not to speak any numbers for an hour. If you can help your people cooperate and talk to each other, they don’t need a formal procedure. If you can’t, feel free to introduce Planning Blackjack or Planning Roulette – you will likely fail anyway.

And to close, we feel that we must bring up our main point about Agile again:

Agile process is what works for you and your team. Don’t hesitate to introduce changes if you need to.