Russell Bateman
August 2017
Story points are a unit of measure for expressing an estimate of the effort required to implement a product-backlog item, usually a story. Story points are generally assigned from a set of numbers,
{0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ }
—the face values on Scrum poker cards. These values are relative, that is, a story assigned 2 should be about twice as much work as 1, though in terms of personnel or team members, a junior member would take longer presumably than a senior team member to accomplish the work.
Most importantly, story points are not based upon any, tangible time period like days or hours.
The story point is chosen based on...
Calling the story point a point in the Agile process when it is really anchored in the number of hours or days to complete a story introduces needless complexity and loses one of the main benefits of story points.
It is true that it takes time to complete a story and time is measured in hours, but story points are only helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively. If they're about hours, then you completely lose their value as a measure of velocity!
Review the example in part 1.
A senior and a junior developer can begin by estimating a given story as 1 point, or 2 if they agree that the story will take twice as long to complete as a 1-point story. If story points are equated to hours, this estimation can no longer be done. The story will take the junior developer perhaps 10 hours to complete while the senior developer can do it in 5. Making it a 2-point story because knowing that the senior has other priorities forcing the junior to do it falsifies the ultimate velocity. When looking back on the velocity of the many sprints a team has done no longer tells management anything since the points don't mean anything relative to themselves.
When story points are equated to some time period, team members are taught to think about the story in terms of how long it would take them to accomplish it. When the poker cards go up in sprint planning, the senior team members have different answers than the juniors. Bargaining begins, but it's really a discussion as to how long it will take. Even if a compromise is agreed upon, it falls short of giving the story its arbitrary, but relative estimation that will be invaluable over time and more sprints as a velocity for the team.
Story points aren't cross-relevant between teams. The velocity number (story points completed per sprint) of your back-end development team cannot be directly correlated to your UI team's numbers.
So then, how do you use story points?
The product manager maintains a back-log. Management propose new work for the team which the product manager reduces to epics and stories. Then, the team assign a number to the stories. As soon as this happens, the team's velocity can be used to estimate the time to complete the new work and the release date:
The number of sprints to complete new work:
number of points estimated for all stories / recorded team's velocity
The completion date for the new work:
number of sprints to complete new work × length of sprints