What's the Story on Story Points?

Say you are sitting with your scrum teams, planning for their sprints. When suddenly, a colleague barges in, professing they are now a 10X engineer.

"Why?" everybody asks, to which he exclaims "because your average sprint velocity is 10 story points, and I closed at 100 points last sprint! "

Story Points are Nothing and Everything

Story points are an abstraction used to measure the EFFORT in delivering a piece of work from your backlog. Dates and hours measurements don't include scope-creep or business-as-usual (BAU) items creeping in. We also know that dates don't play well with software engineers, having a detrimental effect on their work in the long run.

Why use an abstract measurement? To quote Mike Cohn's Agile Estimation and Planning:

We are better at estimating “this is like that” than we are at estimating the absolute size of things

Suggesting a shift from “my part will take 3 days and yours 6, therefore its 9 days” (which will be certainly inaccurate) to “overall this effort seems to be the same as the one we said was hard, therefore this is 4 pointer and we know we can deliver 7 story points a sprint – so this is going out this sprint”.

We switch from time to size because, we need to know how much software increments we can ship. Sprints, and for some of you out there: Program Increments (PI), are all about deliveries and visible increments.

If Story point estimation is done right, you will inspire good requirements capturing.

Story points are meaningless without a velocity.

And a velocity is only possible with consistency, this being:

• The number of team members
• The time-box (sprint)
• The consensus of the story point metric.
• All unchanging across a long period of time.

Using story points with a time-box causes large and uncertain pieces of work to be broken down into VISIBLE and ACTIONABLE increments. This abstraction helps to create certainty, visible delivery, commitment and consensus to the solution you wish to deliver.

Teams work in different velocities and with different opinions on what constitutes complexity and difficulty. The team is consistent though, therefore the Story points are stable - 1 story point for an easy piece of work now, should be 1 story point for an easy task next year.

Pitfalls in using Story Points

Story points should not be used in ranking and reviewing individuals’ productivity. The team is assigned the story, because the team has a predictable velocity not the individual. 

A story is a software increment not an individual task. E.g. “Provide this API for XYZ”.

• To deliver this story, you need to: code in the logic, test the logic, provision the infrastructure, deploy the piece, etc.
• If a similar historic story was a huge effort (8 story points), barely delivered in 2 sprints, then we know that we need to break this down into 2 manageable stories: Create the API - and - Create the Infrastructure. Both 4 story points, which we know through consensus that we can definitely increment 4 story points every sprint.
• BAUs are the exceptions here, and are efforts we have to do to maintain the business. 
• There is no issue if the capacity drops in a sprint. In the long run everything normalizes and the product owners (POs) can still estimate on the average velocity.

What about our 10x engineer in the introduction, closing 100 story point against the team's average of 10 - this is stuff of stars!

That number doesn't mean that they were 10 times more productive than the others. It only means that they were not part of the team and was operating on their own cadence and preconceptions.

Any Alternatives?

If this abstract measurement doesn’t work for you or your team, the next best alternative is ideal days.

If you want to cross over to digital taylorism with worker surveillance, clocking every second and applying dystopian scientific-management to a software house of creative and talented problem solvers - Measuring Person Hours is the hill to die on. 

Achieving the Best Estimates

• Use retros to recalibrate your definition of story points and/or find reference story points that fit that definition, which you can compare to.
• The best estimates always come from the story’s implementers.
• Items deep in the backlog should have a rough estimate erring on the side of an overestimation, until the planning meeting.

Burnups and velocity charts will give you the necessary feedback to mitigate and improve your sprints, PIs and the teams' experience. These are generally populated through the use of story points.

The Burnup

The blue line denotes the number of story points (i.e. size of features not time), the green line denotes the team's progress to completion.

Add BAU or lose capacity and the green line drops - reducing the progress to completion

The Velocity

The blue bar is the commited work while the green is the delivered - we always think of delivery size not time.

With this, we can predict how much scope we can role out within a sprint. It also allows us to understand our limits while defining the amount of scope we can go for.

References

• Mike Cohn Agile estimating and planning
• Story Points: Why are they better than hours?

Github

Code and article shown here are available on github .

This Article by Adam Darmanin  is licensed under CC BY-NC-SA 4.0