In a recent agile podcast, one of the hosts said that story points existed “just so that some manager can get a report.” That opinion might fly in a fantasy world where investments are made without any sense at all regarding what value might be provided, but that’s not how the real world of business works.

Now of course, the pendulum can swing to either extreme. On one side, there is the belief that estimates aren’t necessary because they are simply an evil imposed by numbers-obsessed management, and on the other, people who take story points, divide them by the average velocity, and set hard-and-fast scope and timelines based on that math. AS with most things, the reality lies somewhere in between.

We know that story points are a guess. All estimates are a guess. At the beginning, when we know the least about the problem we are solving, it needs to be understood that estimates will likely grow to deliver the scope, or the scope will need to be reduced to meet a timeline. However in a business, unless it is a pure research project, usually someone is putting themselves, or the organization’s reputation, on the line by sponsoring this. Multi-million dollar rollout plans may hinge on this work. As professionals, we need to set expectations. That doesn’t mean we should be cowed into sizing something we don’t understand, conveying a false sense of confidence over sizings, or providing low estimates to make someone happy in that moment. As an initial release plan is being formed, story mapping is done, and epics and some stories are identified, the team will identify risk and uncertainties. Those are used to convey the overall sense of confidence (i.e. “this is just like that thing we did last year – we got this” or “we haven’t solved this business problem before, and we’re using a new technology stack – we’re going to need some flexibility on scope or timing”).

In addition to setting expectations, story points sizings help the team develop an understanding of what they are going to build. In backlog grooming/refinement, it is fascinating how a team can have a nice conversation about a user story and seem happy with its understanding of what needs to be done. Then there’s that moment when the Scrum Master asks them to size the story, and the conversation all of a sudden gets real and uncovers deeper information and concerns about the work involved, the requirements, risks, etc. Without this conversation, the story could have been included in a sprint, then morphed into a multi-sprint behemoth, the kind that just can’t seem to get to ‘done’.

Reflections:

• We owe it to the business to provide some sense of sizing.
• The business may need to be educated about what story points are and are not, and how sizings can change as our understanding changes.
• Use story points for good, not evil!