In Agile, we strive to deliver small, incremental value to speed delivery and minimise risk, so how are your SPs distributed?
In Agile, we talk a lot about the delivery of valuable software through small, incremental changes. We embrace the fact that smaller changes not only enable teams to be more responsive to changing business and client demands, but they enable us to deliver faster and minimise the risk profile of changes to your live product. But how do you know if your teams are effectively breaking down big ideas into the right-sized stories for delivery?
As critical as this process is, we find several Scrum teams still overlook one of the simplest yet most robust metrics in the Agile library: Story Point distribution. This metric enables you to evaluate how many of the stories you delivered are distributed across the spectrum of standardised story point estimates.
Ahead of jumping into the metric, let’s revisit some of the basics. In Scrum, teams will evaluate a story and assign an abstract estimation based on the complexity and risk of the unknown. As complexity and unknowns increase, so does the story point estimate assigned (most commonly on an exponential scale).
To minimise the risk associated with complexity and unknowns, teams work collaboratively to break down stories into smaller, more simplified stories, and aim to alleviate the unknowns throughout this process. The result should be several stories/tasks that are more straightforward and have much smaller risk profiles associated with them (represented by smaller Story Point values).
Most teams have adopted the Fibonacci Sequence as the standard for Story Points. Whether you use this or another standard, the important thing here is to ensure you have visibility of how your actual stories are distributed across the spectrum of standardised estimates. Your objective is it minimise (or eliminate altogether) the delivery of large stories by breaking them down into smaller, more well-defined stories.
Where you draw the line on what’s “too big” is somewhat subjective for each team, however, there are some standard targets that many organisations adopt. If you use the Fibonacci Sequence (i.e. 1, 2, 3, 5, 8, 13, 21, etc), the line is most commonly drawn at 8. You may accept some 13s when technical and functional complexity are so intertwined that a story cannot be broken down further, but most teams will still strive to keep the far majority (~90%) of stories at 8 and below. Again, you will need to adapt this to how you use the sequence for your estimates (i.e. an 8 for one team may be a 5 for another team and a 13 for another team).
In the example above of Story Point Distribution, you’ll see that the team has a relatively healthy distribution across the possible estimates. There’s possibly some work to do to continue to drive down the 13-point stories (and we certainly want to avoid any further 21-point stories), but generally, this team is effectively delivering smaller stories.
Some things to look for:
- Do you see values appear that aren’t in your standard? This is a common issue and one that’s easy to fix by ensuring teams stick to the standard.
- Are 90% of the stories below the right threshold?
- Can more work be done within the target range to continue to simplify stories (i.e. turn 8s into 5s and 3s)?
Setting up Story Point Distribution
In Plandek, you can easily set this metric up by using the Completed Tickets metrics. Simply add it to your dashboard, and then apply a filter on Issue Type = Story and add Story Points as a breakdown.
How can you be more proactive?
Rather than relying on insights retrospectively (i.e. after stories have been delivered), Plandek also enables you to monitor and take action ahead of development starts. Below we see the current distribution of Story Points in the backlog. You’ll notice that there are a disproportionate amount of 8 and 13-point stories (compared to 1 to 5s), so this will alert the team to be able to focus on these in the short term to see where they can break these stories down further.
To set this view up in Plandek, simply add the Unresolved Tickets metric. In the metric settings, filter Issue Type = Story and Current Status = [those statuses before development starts]. Make sure you add a Breakdown by Story Points so you can see how these stories are distributed across the different values.
