After many years using Scrum and lots of companies later, I have seen that people have a tendency to assign timings to story points like 3 points = 8hour work. This is bad for planning and makes you unable to use one of the properties of Scrum.
Let's start by quickly recalling the point of the story points and what do we seek to obtain by using them.
Software development teams aren't usually a uniform mind of similar expertise and experience, some people are better at the backend, some have more years of experience, and so on. These differences make them think that they can solve a particular problem in X hours but that X greatly differs on value from member to member of the team and add to that the fact that we, software developers, are way too optimistic at estimating timings. How can we solve these problems?
Fortunately, software developers are extremely good at assessing the complexity of a problem and the appraisal difference between a senior and a junior regarding complexity is not that big when compared to difference while comparing timings.
So, by relating story points to the complexity we gain a more general consensus about the workload of a given problem thus allowing the team to be able to predict how much complexity they can tackle on a given stretch of time.
Important things to take into account:
Always remember that this is an iterative process that yields better results the more iterations it runs, so don't expect the first sprint to nail the points.
Never ever change the points assigned to a story. One of the things you expect to gain is predictability and for that, you need to maintain the same error pattern your team has. If you change the value of a story after a sprint that pattern will be blurred or directly lost.
It's the product owner job to translate the amount of complexity a team can tackle into timings for upper management and that should never be a concern for the developers.
If you reduce the number of story points to fit more complexity on the sprint you are only cheating yourself.
Top comments (1)
Thank you! This is the blog post I've been meaning to write for quite some time. Story points are a measure of complexity, not time. Eventually, people learn to judge complexity: is this code we're going to change something we've worked on lately? Does it have good test coverage? Was it written by someone who is no longer on the team, or worse, a founder? Does the story depend on external vendors and APIs? New and unknown technologies or frameworks? Add more points for each bad answer.