What is the story behind storypoints?

I have seen them quite often, and often they are not used in the way they are supposed to: storypoints. When used correctly their potential is very practical, but it can go wrong in ways even team members don’t know what to do with them. In this article, I dive into the basics of how to work with storypoints, and I also look at a relatively new trend: #noestimates.

The basics

Storypoints are a relative estimate of how much work a task, story or Product Backlog Item (PBI) is. Relative to what? I hear you ask, and that is where the core of storypoints comes in mind. It is relatively to each other. A PBI of two storypoints is dus (about) twice as much work as one of 1 storypoint. It’s nothing more, and nothing less than that.

The idea behind this, is that people are very bad in making a time based estimate. An estimation like “It’ll be ready tomorrow” is rarely true. Especially in the complex environments Scrum is being used. People are far better in estimating relatively. So comparing PBIs with other PBIs.

This estimate is bound to the team and situation. That means that team A can estimate something way different than team B. This is similar with the environment the team acts in. That is why it is wise to poker PBIs again when they haven’t been pokered for a while and are about to be picked up. Additionally, consider not estimating stories too far in the future, as a rule of thumb, about two sprints into the future.

In day to day practice I use storypoints in two different ways. It is a means to look forward and back: if last sprint had a velocity of twente storypoints (twenty storypoints worth of PBIs was actually finished), then you should start questioning when the team is about to start a sprint containing 40 storypoints. If you consistently burn 40 storypoints in a sprint, and all of a sudden you have a sprint where you burn 80 storypoints, it is good to investigate what went so very good in that sprint.

The second way I use storypoints is to determine if stories should be split up or not. Imagine a team usually has stories which have about three storypoints and they have a velocity of twenty storypoints in a sprint. If, during refinement, they estimate a story to be 13 storypoints, that would indicate quite an amount of work. Then I would start a discussion with the team to split the story op and clarify more how much work a story is.

Formally, storypoints are not part of scrum and aren’t mentioned in the scrum guide. The only thing about estimating in the scrum guide is that work is estimated by the developers. How you do this is completely up to the team, and that liberty means that you can also make this estimate in a way which works for you.

Estimation

It is up to the team to pick a way of estimation which fits your needs. There are some tips and trick you can use and which could help by properly estimating the backlog. A few follow.

Baseline

As a starting point you can use reference stories. Pick a story, which is about a average amount of work for the team. So about 50% of the work is more, and 50% is less. this story is given 5 storypoints. Then take a story which is about twice as much work, and rate it 10 storypoints and one which is about half the work of the first one and give it two points.

It is good to regularly revisit this baseline, because as the team progresses, the stories could get more complex or maybe they learn to work without certain parts of information. If most of your stories end up having just one storypoint, it is worth considering revisiting the baseline as well, because that makes it very difficult for the team to differentiate between bigger and smaller stories to keep it usefull.

Fibonacci

An estimate of 38 storypoints might give you the idea that it is an exact number, while it’s always an estimate. A discussion whether a story has 38 or 40 storypoints, is not that interesting. That is why stories are usually estimated using a form of a Fibonacci scale: 1–2–3–4–8–13–20–40–100.

An alternative to this is to use a scale which is not liked to numbers, but other objects. Something like cat-mouse-elephant or T-shirt sizes. The advantage is that it makes the story more difficult to plan, a disadvantage is that it is very difficult to compare stories to each other, which is actually the point of estimating them this way.

Poker

To get an unbiased opinion of the team, often a form of scrum poker is used. It goes like this: during refinement someone gives a short summary of the story. After that, all team members pick an estimate in Fibonacci scale. This estimate is shown when everyone has picked a value. Because the team members interpret the story differently, this leads to different values and a discussion, with which you further refine the PBI. This process is repeated until everyone (approximately) agrees.

A disadvantage of estimating in this way is that team members who don’t know a lot about the subject can have difficulty participating. The threshold to really add some insights is quite high. Whilst it is good to have everyone’s opinion on a story, because exactly that one unbiased question could bring the PBI in a wholly different direction.

Against estimating storypoints

I have seen an emerging trent to stop estimating the backlog. The estimate based on storypoints is often not used in a way it is intended. For instance, entire project plans are hung on these estimation, or a manager who asks why velocity is so low. Often the team treats storypoints in unexpected ways as well. I have seen situations where storypoints are translated into days or a Product Owner who fills in the estimate himself.

So that’s why I understand a wish to investigate other ways to deal with this. There are several different initiatives to deal with this, usually accompanied with the hashtag #NoEstimates. Some say to reduce PBI’s to the point they are all approximately equal, or only estimate whether the given PBI fits within the sprint time window. There are also sounds to forgo estimation and only work on the PBI with the highest priority. Each of those has their own advantages and disadvantages. I haven’t tested them in practice yet, but they are definitely worth investigating.

Closure

In this article, I briefly explained the how and what of Storypoints and estimation. Including examples of how it is done, and how it’s not supposed to be done. At the end of the story I dove into #NoEstimates and how this trend tries to counteract the planned based storypoints.

Storypoints are almost as old as the Scrum Guide, but they’ve never been in there. There are so many ways storypoints are being used for show or because “that’s how we always did it.” When used properly, they are a very powerful tool to give insight. When used improperly, they are just a nuisance.

So, how do you estimate? Did you use the mouse-cat-elephant, or T-shirt size?

Images: the first image (book) comes from freeimages.co.uk. The image with the poker cards is from freeimages.com. The #NoEstimates image has been self-made.

Expected a Dutch blog post here? To widen the audience for my blog posts, I have decided to translate some of them in English.