by Tristan Bagnall
Recently I have been asked quite a bit about story points here are some of the answers I have given.
To give some context and scope around this post, here are some quick facts I have learnt about story points:
- For story points we use an altered fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 40 ,100. (Some tools use 20 instead of 21)
- Story points are abstracted from elapsed or ideal time.
- They are like buckets of accuracy / vagueness.
- The larger they are the more assumptions they contain, the larger the probable complexity and therefore effort.
- They are numbers, allowing the use of an empirical forecast
- They are used by the Product Owner and enable them to do forecasting - the PO should find themselves being asked, when will I be able to have a usable checkout (or other feature).
- They are used on user stories a.k.a. product backlog items (PBI)
- Epics are included as user stories, even though some tools have adopted a taxonomy that suggests Epics are different to user stories.
- They show the relative effort and complexity of a chunk of work.
- They are a vector - 8 story points is 4 times as much effort as 2 story points (4 x 2 = 8)
There is plenty of literature out there about story point, estimation, etc. This is not meant to be exhaustive, but I would encourage everyone to read about them.
Why not use man days instead?
Everyone has an opinion on what a man day is - it is kind of mythical as it means so many things to different people.
Man days suggest that there is little complexity and we are certain on what needs doing - after all days can be divided into hours (24ths) so they are very accurate.
Man days also start give an expectation of a delivery date, even if they are padded out by saying they are ideal man days. However once you start with ideal man days you then get into confusing realms of what is ideal and what is really happening. For example:
- 1 man day, might be 2 ideal man days as the person is only spending 50% of their time on a team (a 50:50 split).
- But in reality they are context switching every 30 minutes, so the time split is really less than 50% - context switching is very expensive and leads to poor quality work. So the real split might be something like 40:40:20.
- This suggests that 5 man days are really 2 ideal man days.
- At this point normally a large debate starts, with boasts about how easily someone can context switch and these (or any) figures are wrong.
- At the end of the debate there is a lack of clarity and therefore the man days have become meaningless
It is generally accepted that it is better to work out the effort and then measure how a team progresses through that effort.
Why the sequence of numbers?
As we continue to have conversations about an item of work we get to know more about it, we therefore learn about its complexity, we remove uncertainty and get an idea of the effort involved to deliver it. While we do this we break the work down into more manageable parts. Through all this we are testing assumptions, either removing them, or correcting them or validating them.
As we gather all these moving parts we can become more accurate about how much effort is needed. While it is big, we have a lot of assumptions, and due to that we are pretty vague.
So how does this tie back to the sequence of numbers?
As we can be more accurate with the smaller items we need more buckets that are closer together to put the chunks of work into. Therefore the first part of the sequence is ideal: 1, 2, 3, 5, 8.
Then we have the large chunks with lots of assumptions - the epics - that need to be broken down before we can work on them: 40, 100
Then we have chunks that we have become more familiar with, partially broken down, but are still too big: 13, 21.
How small should a user story be before I start working on it?
Another way of putting the question is
- how much uncertainty should remain;
- how many assumptions should be cleared up;
- how effort should there be;
- can it be finished in the sprint - meeting the Definition of Done?
before I pull a user story into a sprint or into progress on a kanban board?
This depends on several factors:
- How much uncertainty are you comfortable with?
- How will the remaining assumptions affect your ability to deliver the chunk of work?
- What is the mix of the sizes you are pulling into a sprint?
As with all things agile there are exceptions and generalisations. One observation I have made is that many teams think that they can take large chunks of work into a sprint, however this means there are lots of assumptions still to be worked out, lots of vagueness and uncertainty. This leads to a lack of predictability and consistency on the sprint delivering.
Therefore I have normally advised the largest single chunk going into a sprint is 8 story points, but there should always be a mix of sizes going into a sprint.
