AGILE TOOLBOX
How To Estimate In Story Points?
Estimations 101
Have you ever done work around the house or built a new one? Construction is probably one of the best examples of how bad the estimates can go. And it goes hand in hand with the weather forecast. Apparently, we are much better at relative estimation.
Following up on the video “Don’t sweat estimations”, let’s learn how to estimate in story points, unlearn estimations in hours. And play some Planning Poker.
Let’s start from the beginning. Why do we even estimate in the first place? In my previous article I talk about four reasons for estimation:
- Arrive at a shared understanding among the team members,
- Organize the Product Backlog based on value and effort,
- Plan upcoming work,
- Slice the stories and work smaller.
Estimation helps the Product Owners decide if something’s worth doing. The PO assigns the value and the team defines how much effort it will take to deliver this value. Based on both, the decision about what to work on next will be more informed. Besides, the estimation inspires the teams to slice stories and work smaller.
Manager’s perspective
Put yourself in your CTO’s shoes. There is a new idea to improve the product. You have some customers interested in it. How do you plan for it? How do you calculate the ROI? And how to manage the potential customer’s expectations? What you want is an estimation. You want to have an idea of a delivery date. So you can understand how much money this investment will cost you. This point is directly tied to the next one, why we tend not to estimate in hours.
Why not estimate in hours?
First of all, one hour in developer’s time doesn’t equal one hour of delivery time. There’s other work to take into account too. You have to plan for it, think about it, talk about it and then develop it. It also requires translations, education, and roll-out efforts. All in all, it is a complex endeavor.
What’s more, if you estimate in hours you run a risk of having a lot of discussions based on the seniority of the developers doing the job: for you, it’s 3 days but for me, it’ll be at least 5.
And last but not least, people get caught up on time estimations: you said it will be done in a week, so what are you doing here working on it for a second week? Estimating in time is easily taken as a guarantee or a blood pact rather than an estimation. Does it make sense?
What are Story Points?
Story Points are units of measure.
Story points are abstract, relative, and about effort.
What matters is that we estimate the effort. And the effort does not equal time. Therefore, it should not be simplified to just hours. The effort is directly affected by complexity and other factors. To name a few, think about the dependencies, risks, uncertainty, testing, whether you do unit testing, automated tests, the repetitiveness of work, criticality, and others. What do we estimate then? The complexity of the whole solution, up until meeting the Definition of Done.
How do we estimate?
It’s important to underline that the estimation is done only by the people who do the work, the Developers* in Scrum. Product Owner, Scrum Master, and an Engineering Lead have nothing to say here unless they are coding too. Of course, if the estimation they get is far off from what the PO thought it could be, they should ask questions because maybe the is a misunderstanding between what was asked and what is being estimated.
Fibonacci numbers
Probably the most common way to estimate is to do it in Fibonacci numbers. Each of the numbers is the sum of the two before it. It is a great relative measure as you can fit different items into each other.
Planning Poker
In order to be able to estimate, you need to understand the work to be done. A great way to learn is by having conversations about user stories, hence the name. What you would typically expect is that the Product Owner comes to a refinement session with Product Backlog Items and explains the why behind them, the content, and the type of business value they will bring. A good practice is to start from a problem we want to solve for our end users. It gives the team more context. Then the Product Owner explains the acceptance criteria and whenever the team feels they are ready to estimate they can start the Planning Poker.
Each Developer has a set of cards with Fibonacci numbers on them. From my experience, it makes sense to have the numbers from 1 to 13, as after thirteen you can basically put the infinite sign but, of course, it all depends on the scale the team adopts.
Once the team is ready to estimate, all Developers choose one card that reflects their estimation and show it at the same time. It is called Planning Poker because we encourage keeping a poker face while playing it. This way we avoid biased estimations and everyone estimates on their own. If the scores differ, we have conversations to understand each other’s points of view. This is a very nice activity to play face-to-face. However, might be a bit complicated in a remote setup. Fortunately, there are many online tools great for distributed teams.
Learning to estimate in relative numbers
If you are a Scrum Master or someone who wants to teach a new team how to estimate, you can prepare an estimation kick-off session. One good way to run it is by explaining a reference story and triangulation techniques.
Reference story
When a team is new to estimations, it’s good to identify some reference stories. Some sample stories that could represent a few of the first Fibonacci numbers like 1,2,3,5,8, up to 13. Of course, the team can choose to estimate in any other way, and that is perfectly fine. If the team decided to stick to Fibonacci, let’s see how to do it.
Since relative estimation is about relativity, first identify the smallest story you can think of and assign one story point to it (1SP), this is your primary reference story. Then relate any other stories to it and identify other numbers. Keep a list of those reference stories for future reference.
Triangulation
Triangulation is checking not only a reference of the same number but the two around it. For instance, if you consider an item to be a 5, get a 3 and an 8 and see if it really is in between those.
You can have a table with one or two reference stories per Fibinacci number so when the team estimates they can use it for reference in their first Refinement sessions. I try to avoid calling these sessions “Estimation” because then people focus on just adding points to stories instead of actually understanding and refining them. So I call all sessions “Refinements” to keep the attention on the goal and the estimation as a side effect.
And this is how you get familiar with estimations. I hope this article will help you understand better the story points and ultimately give more consistent estimations. It will not only help the team plan the work for the Sprints but also help the company and the CTO get a grasp of the complexity and cost of any new development. Just let me underline it again, it is not a guarantee or a blood pact, it is a relative estimation to know if we are talking about weeks or months of development. And when a date is set, then thanks to having a fairly stable velocity, you can take a more informed decision in order to descope the initiative and meet the deadline.
On an ending note, I’d like to leave you with Ron Jeffries’ quote. He is one of the founders of Extreme Programming (XP) and one of the inventors of relative estimation. When asked if he regretted the invention of story points, he replied:
- I certainly deplore their misuse;
- I think using them to predict “when we’ll be done” is at best a weak idea;
- I think tracking how actuals compare with estimates is at best wasteful;
- I think comparing teams on quality of estimates or velocity is harmful.
Ron Jeffries, Story Points Revisited
*New Scrum Guide calls all team members aside from Scrum Master and Product Owner, Developers.
