Human beings are not very good at seeing into the future. Unless you have a crystal ball or know how to read tea leaves, trying to predict when an event will happen with any degree of accuracy is very difficult. Unfortunately, as software developers, we are regularly asked to do this. Stakeholders usually want to know when they can expect the completion of features. It can make them nervous if we tell them that we don’t know for sure, or give a time-frame that sounds worryingly large to them to account for our uncertainty. Story points attempt to solve this by sidestepping time-based estimates, and focusing instead upon estimating complexity — on the basis that we are better at judging how complicated a piece of work is than how long it will take to complete. Estimating complexity allows us to abstract away things that we can’t reasonably predict (and often throw off our predictions) such as illness and distractions, and focus on the things that we can — like whether one task is going to be bigger than another. Once we have a way to quantify complexity, it is possible to begin to measure how much of it can be tackled over time — this is known as velocity. Measuring a team’s velocity allows us to build forecasts of how much work they are likely to be able to complete in the future. Note the word in that last sentence. Story points are not a silver bullet that will let you make perfect predictions about when a task will be finished — but in my experience, they are a significant step up from trying to estimate time directly. likely They help you shift from hand-waving and guessing, to evidence-based reasoning about a teams capacity. Over time I’ve found that the accuracy of story point-based predictions tend to improve as teams gain practice and experience, and as the error in velocity averages away as more data gets added to the calculation. Story points can be a contentious topic amongst software professionals; a lot have had bad experiences with them, and don’t see how they can ever help on a project. While I don’t think story points will be a good fit for projects, I do believe that they can be useful on of projects — especially when teams are inexperienced and haven’t had a chance to build up some discipline. all a lot I regularly hear two objections to story points that, in my opinion, betray underlying flaws in peoples thinking rather than a problem with the technique itself: Firstly: that the complexity of a task is different depending on whether you have more or less experience, often stated as ‘my points are different from your points’. Secondly: that there is ultimately no real difference between complexity and time — ‘five points is about a day, this task will take about a day, so I vote five points’. The first objection is problematic because you should be estimating for the team, not individuals. If a task is going to be harder for a particular person to complete, then the team should be working with them to help. If you expect someone to struggle to complete work by themselves with no assistance when it would benefit them, then you have more significant problems on your team than estimation. It would be best if you focused on fostering collaboration and knowledge sharing before worrying about anything else. The second objection is harder to help people move past. The cognitive leap from time-based estimation, to complexity-based estimation, is quite a large one. The easiest way that I have found to help people get into the right frame of mind is by agreeing on a story to use as a reference at the beginning of estimation sessions. The question then becomes ‘how much larger is the story we are currently estimating than our reference story?’ When they don’t have a lot of experience with relative complexity, people often find ranking stories, and then fitting points to them later much more straightforward than coming up with points on the spot (as you would with planning poker). With a bit of time and practice, most teams can build up an implicit understanding of how story points relate to the complexity of individual pieces of work in their backlog. As a team becomes more practised, a satisfying moment eventually occurs: everyone’s estimates begin to converge. You know that your team is getting the hang of things when everyone is consistently voting for the same number of story points on each piece of work that comes up; and when any significant variation that occurs is the result of someone knowing something that the others haven’t considered. Whether or not you use story points on your project, I think there are some ideas we can learn from them that are universally applicable. Almost all projects benefit when we can quantify changes to them over time. Reflecting upon, and learning from our experiences is a crucial part of agile development, and doing this with data can give us confidence in our conclusions, and justification for our predictions. Previously published at https://davidcapper.dev/posts/getting-your-head-around-story-points
