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:
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:
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
before I pull a user story into a sprint or into progress on a kanban board?
This depends on several factors:
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.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.