Story points are designed to give an indication of complexity. Their purpose is to help estimate a task. They also help to calculate velocity and aid release planning/forecasts.
Scrum does not recommend any particular estimating approach but arguably the most common approach is story points (I believe its origins are linked to Xtreme Programming).
The development team are responsible for all estimates and are the only people who are allowed to assign a story point value. As a team gets more and more used to estimating, the general feel for how many story points a task should be, should become easier to predict and assign. To help people become more comfortable with assigning story points there are aids such as planning poker cards that can be good until there is a good level of understanding within a team.
Our field is multiple choice following a modified Fibonacci sequence of; 2,3,5,8,13,20,40,100. 2 is the lowest value in complexity and 100 is the highest.
Why choose this approach over other methods?
Story points are quick and easy to assign. They’re purely relative, people are much better at comparing the relative size of things than they are at making absolute estimates in days. They remove disparity of different skill levels. As they are numeric we are able to use the values to track velocity. The tendency to link a delivery date to an estimate is removed with this approach, stakeholders won’t really be able to interpret a fixed delivery date with a story point in the same way they would with days.
Why not use time?
Easily the most common question I get asked is why not use time. If we had to estimate in days, hours, minutes we would have to get really specific on the detail of the task up-front – we would have to know pretty much everything in order to give a reliable estimate. I’m sure we all know that this is near impossible for something as complex as software development. Despite all the planning upfront, as soon as we move into a code editor we see things we didn’t foresee and the estimate would need to be modified. This approach can be costly on time. By all means, if you feel like you want to use hours or days as a general measure, you could associate a point with a rough measure of time – 5 is half a day for instance. As long as it is consistent it is fine to approach giving a story point anyway that is good for you.
Tips I’ve learnt along the way
The easiest way to assign a value is to compare it with similar jobs. If you have amended a service booking form in the past and that had a value of 13 and the task that has come in is similar to that one then it would be another 13. If it is slightly less complex it would be an 8 – a little more involved it would be a 20 – double the work of the original because say we need to add two options rather than 1 it would be a 40 etc.
We should always air on the side of caution. The goal of a sprint is to get all of the planned work across the board from the backlog to the complete column within the sprint. That is the ideal place to be. Far better we have to bring work across from the portfolio backlog because we have over-delivered than to have to carry work over to a next sprint or push work back into the portfolio backlog.
When a task first comes in and it is what I’d call an epic, we would like to give it a story point to aid scheduling but (and this is especially true if it isn’t going to hit the schedule anytime soon) we wouldn’t want to be worrying too much about the detail, I’d generally use a T-shirt sizing approach for this. Small = 5, M = 13, Large = 20, XL = 40 and XXL = 100.
We know that as we get to work on the task and details unfold the epic will be broken down into smaller tasks (what I’d call a Product Backlog Item – PBI) and they’d have a more accurate story point assigned to them and really it is these jobs we will be bringing across into our sprints – not the epics.