No. In fact, Scrum isn’t prescriptive about any particular measure for measuring the complexity or time commitment of any particular task, let alone story points vs. hours. Many practitioners support story points, but others support hours, days, or portions of days. You should do whatever you and your team feels most comfortable with.
Definition of Story Points
While many practitioners laud story points, there is no real consensus on what a story point is. Derek Davidson of Scrum.org makes a good attempt when he says:
“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements.“
There’s a couple of important take-homes from this description. First, it mentions that the measures are decided upon by “individual Scrum teams”. That means it’s a measure that can’t be used across scrum teams. Second, it notes that story points provide “relative estimates of effort” by the team, not the individual. Finally, there’s no mention of time-based estimations, which is a hallmark of story points.
Benefits of Story Points
Advocates of Story Points believe it has many benefits. For instance, they believe that story points are less stressful for developers, who won’t be held to specific hours. They enjoy the fact that story points make it more difficult to compare between teams, so that there’s less competition. And they also story points as less deflating to team members who may be a bit slower than others. Finally, they conclude that story point estimation can be faster. Team members aren’t worried about making a commitment that is both reasonable and praiseworthy.
Benefits of Hours
While Scrum professionals often espouse story points, there is still a significant debate on the issue. Backers of hours believe the nebulous definition of story points makes estimating via hours more straightforward. And because hours are a ubiquitous measurement, management can use them to compare between teams, and not just within them. (Under very specific circumstances, to be sure.) They also point out that external stakeholders need more precise information. No manager wants to hear how many “story points” it will take for a task to be complete. Finally, they note that story points require specified training to understand.
Eban Escott of Codebots makes one of the best analyses we’ve seen that espouses hours, but they’re hard to find.
Should You Use Story Points Or Hours?
The jury’s still out on whether story points or time-based measures are “better” for Agile project management. When deciding between story points vs. hours, we recommend you work with your team, present both options, and see which they are most comfortable with. You may even care to experiment with both, which may break up the monotony of your Scrum ceremonies. Whatever you decide, do not fret about what other people think about your team’s decision; too often we hear that there’s a “right way” of doing things, when what’s important is whether it’s right for your team.
Let us know your opinion on the matter, and feel free to be scrappy! Happy Scrumming!