To the Point

Instead of wasting time estimating story points, spend that precious time understanding the requirements. Figure out how to break them down into smaller and more valuable stories, and deliver less volume and higher impact.

Base all of your work and planning around small stories. Your predictability will increase. Your customers will get more frequent deliveries of truly valuable functionality. And you will have an overall happier and more engaged development team.

What do Story Points Provide Your Team?

If you are using story points:

• Did you ever ask why?
• Did you ever track the accuracy?
• Or ever track the consistency of story points to any other metric?
• Have you ever considered the effort required to guess at the story points?
• What is the return on investment of the time spent generating a guess of dubious accuracy?
• Do customers ask for Story Points?

The primary reason that Ron Jeffries and the XP team pivoted from estimating in ideal hours or ideal days was because of the confusion this practice caused. The unit of measure was well understood by business people. But the concept of “ideal days” was not. So turning to a made-up value and calling it “points” was a way to discourage the business folks from wondering how a three-(ideal)day effort required a week of calendar time.

Though Scrum does not dictate using Story Points, it seems everybody does so.

The Problems with Story Points

The problems I see with Story Points

• The fact that people use numbers gives an illusion of “we know what we are doing, we have a precise metric.” No matter if you pull out the “but we are using a Fibonacci sequence” – that just exaggerates the degree of imprecision.
• No two teams – maybe, even, no two people – have the same Story Point “Ruler.”
  • Yes, I know we can pick a well-known story as a 1 pointer and do relative sizing…
  • And I know we can work to make all teams estimate story points the same way. Hogwash.
• The activity rarely (never?) reduces the scope
• Estimation is usually coupled with a capacity planning session, further deepening the impact of imprecision on the overall process
• The ceremonies around estimation sessions often miss the point – we are here to understand what needs to be delivered to the user.
  • Instead, the Scrum Master diligently asks for Story Point estimates for the story as written in Jira (because the business is too busy)
    • They get (3,3,3,3,5,5,5) from the team members.
    • They then proceed to ask one of the low number people (a 3) to defend their score, and one with the high number (a 5) to defend their score.
    • Once again the dogmatic ceremonies deliver low-value results
  • Yes, I know there are anecdotes of well-run ceremonies
• NEWS FLASH – you still need to break down the work into meaningful, smaller features. Or at least you should.

A No Story Point Strategy

I have a different strategy.

We deliver features (aka, stories) that customers value. No customer is asking for more story points.

It is better to expend the “story-pointing” energy in breaking down the stories into smaller features. Along the way, we even learn more about the actual needs of the users, and we can frequently find ways to produce more value for less effort by cutting or delaying scope. We do this by bringing the business/subject matter experts, QA, development, and UX, into the conversations. We collaborate to deliver the highest value issues for the least effort. We use story mapping to help defer scope to later releases (or never).

We track completed features delivered.

It turns out to be a pretty stable metric over time – if you maintain the discipline.

If you also track the features you want to build for a given version release (as shown in the graphic), you can get a pretty good handle on time ranges.

(Ab)Using Jira Story Points

I have abused the Story Point field in Jira by setting it up as a signal to the team about simplicity:

• 1 – super easy, maybe a day or two of work
• 2 – A bit more complicated, could be a few days, maybe 4
• 3 – these are never allowed to last long; they must be broken down! They can never be pulled into the “selected for development” column.

The reason I put simplistic values in the field is to allow us to get some Jira reports that use Story Points.

For example, look how we can guess when the release date will be for the set of issues!

Freedom

Try out the strategy of breaking down all features into small, client-valued stories, Make all issues a 1 or a 2 pointer.

If you aren’t reducing (or delaying) scope along the way, you might be doing it wrong.

Remove the ceremonies around story points and base all of your predictions on issues delivered.