Estimation Techniques | First Line Software

Have a Cookie

First Line Software may use cookies and my IP address to collect individual statistics and to provide me with personalized offers and ads subject to the Privacy Policy. First Line Software may use third-party services for this purpose.

Over the years, I’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 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 8 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 (me included) suggest using Fibonacci numbers (1, 2, 3, 5, 8, 13, etc.). Personally I 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 my 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, I 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 him an ice cream or something, and ask him not to pronounce 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, I feel that I must bring up my 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.

Download Case Study

Contact Us


Cambridge MA

1 Broadway,
14th Floor,
Cambridge MA 02142, USA



The Hague

Louis Couperusplein 2,
4th floor, 2514HP,
The Hague

+31 (0) 70 512 1899


Doreen, Victoria

22 Journey Ave,
Doreen VIC 3754


United Kingdom


Cowley House,
12 Black Jack Street Cirencester
Gloucestershire, GL7 2AA, UK

+44 7771 787840

Czech Republic


Na Havránce
1 508/14,
143 00 Praha 12,
Czech Republic

+420 228 883 122

Czech Republic


Centrum, Šumavská,
Šumavská 416/15,
602 00 Brno,
Czech Republic

+420 228 883 122

Send us a note

We'll do our best to answer within one hour