Don’t look back in anger, but some might say that for a simple concept story points may be one of the most misunderstood and misappropriated aspects of the Agile methodology. Story points are neither hours nor money. Hello. Story points are a measure of relative complexity.
Hey Now! The scourge that is Atlassian’s Jira ALM is highly complicit in cementing this misconception, but you don’t have to roll with it. If you feel the need to measure velocity instead of just focusing on producing working software, use hours. As strange as it might seem, a story should never be measured in story points. These are reserved for epics. Story points are used as a proxy when your estimation of a request—more specifically competing requests—has too much complexity to arrive at a number of hours or cost. By definition, this would necessarily be something larger than a sprint. Why? Because if it is small enough to fit into a couple of weeks, how complex could it be? If you can presume to fit a piece of work product into a sprint, you have already determined the maximum number of hours it will take. The maximum amount of time is the duration of the sprint. And if your entire sprint consists of one story the size of the sprint, you’ve probably got some story deconstruction to do.
Stories assigned to a sprint cycle should be in hours. Full stop. No exceptions. Ditto for tasks. Story points are not comparable across teams or even resources within a team. On the other hand, effort can be reduced to hours. If you have two resources, one junior and one senior, the junior one may take eight hours to do the work that the senior could do in one or two hours. This is important when trying to estimate how much work will be done by the end of the sprint. But in the end, the expectation at the end of a sprint cycle is working software.
“I need to mow the lawn and grocery shop. That’s 5 and 8 story points, so I should be over by 19:30.”
We could construct an algebra solution to illustrate how much output to expect for each sprint, but we won’t. More important is the function—the promise of functional software. This does not mean the software needs to be in production—yet. But until the software is in use, it is generating no value, so an overarching goal is to get that working software in production as soon as possible.
But let’s get back to story points. Story points have no place in a sprint. One doesn’t estimate sprint-level work in story points. It’s no defence that Jira allows you to. Atlassian is probably the biggest culprit in spreading bad Agile methodology and killing the agility Agile otherwise might offer. Jira is a process tool and should be secondary to individuals and interactions. It creates a focus on documentation at the expense of working software and change responsiveness. I won’t even get into the travesty that is resource task assignment.
But even if you are lured by Jira, you don’t have to succumb to the nonsensical notion of estimating stories in story points and—gawd-forbid—executing sprint work on the basis of them. If you are doing this, stop. Just stop. It makes no sense whatsoever, and in the end you are probably converting it into hours anyway. So just cut to the chase and measure time in hours—the same way you do with everything else in your life.
I can imagine the domestic conversation:
“What time should I expect you for dinner?”
“I need to mow the lawn and grocery shop. That’s 5 and 8 story points, so I should be over by 19:30.”
This example is no less ridiculous than estimating development tasks in story points. Just stop.