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

Need more details?

Fill in the form and we’ll contact you as soon as possible.

David Tedford

Vice President

David Tedford has over 20 years of sales experience within the IT/software industry. He excels at being immersed in a customer's environment, understanding his customers requirements, crafting solutions to meet those requirements, and ultimately providing solutions to his customers.

Vladimir Litoshenko

Senior Vice President

As the head of business development for First Line Software, Vladimir heads up business development in Western Europe and Russia.

Vladimir began his career in IT in 2002, when, as a student of Faculty of Automation of Computer Science of the First Electrotechnical University (ETU “LETI”), he began his work at The Morfizpribor Central Research Institute (CRI). Vladimir joined the StarSoft team (predecessor of First Line Software) in 2004 as a Junior Software Developer. As he gained experience with more and more projects, he was promoted to leadership roles.

Richard Leslie

UK Business Development

Richard has over 15 years of sales and account management expertise in the IT and Tech sector. He has worked on many outsourcing engagements with global companies.

David Fien


David is a business development professional with more than 20 years’ experience as a specialist in the acquisition of partnerships and IT/software services for associations, not-for profits and corporations in Australia, New Zealand and USA. He has specific expertise in the healthcare, legal and hospitality industries.