Insights from a Scrum Master: Boosting Story Estimation with Flow Metrics

Scrum teams often struggle to estimate how many points a story is worth. It’s no doubt a complex process. Points are a way of measuring the size and complexity of a story, with larger or more complex stories being assigned more points. When stories are estimated correctly, teams can better align people and work, and deliver features with greater predictability.

To make the process of story point estimation easier, I recommend that scrum teams break larger stories into smaller chunks, work collaboratively to agree on point estimates, and use historical data to help inform their estimates.

Let’s recall what user stories are, how we estimate story points, and why it is important to break stories down into smaller chunks.

What are user stories?

User stories are short descriptions of small, vertical slices of the desired functionality, written in the user’s language. Writing them effectively can increase collaboration and creativity and lead to better products.

Here’s an example of a user story:

• As a customer…
• I want to be able to log into my account…
• So that I don’t have to re-enter my personal information every time I order.

Estimating story points

Many scrum teams estimate their stories in story points using the Fibonacci sequence. A story point is a singular number that represents a combination of qualities: volume, complexity, uncertainty, and knowledge. Story points are relative, without a connection to any specific unit of measure. The size (effort) of each story is estimated relative to the smallest story, which is assigned a size of “one.”

Following is an example of relative estimation using the modified Fibonacci sequence:

Why break stories into small chunks of work?

Here are a few key reasons why it makes sense to break stories up:

• Focus. This approach helps teams focus on highly valuable work. This can be viewed through the perspective of the Pareto 80/20 rule, also known as the Pareto Principle, which asserts that 80% of outcomes (or outputs) result from 20% of all causes (or inputs) for any given event. Breaking work into small chunks can help teams more effectively focus on the highly valuable 20%, while deprioritizing the rest.
• Speed. By breaking work into shorter iterations (for example, two weeks), teams can more quickly get value to customers and other stakeholders, and get feedback to guide future iterations.
• Accuracy. Teams tend to be far more accurate in estimating points for small stories than they are for large stories. Breaking a large story into smaller chunks helps teams to gain visibility and clarity into the true size of an effort.

How Flow Metrics can support story point estimation

Flow Metrics, which can be found on the Team Board page in Rally, are based on historical data and can be incredibly useful for scrum teams in improving their estimation accuracy and consistency.

Flow Metrics refer to quantitative measurements of the flow of work through a system, such as the amount of work in progress (WIP), the cycle time (time it takes for a story to go from start to finish), and the throughput (the number of stories completed in a given time period). Please see my earlier blog post for more information on how Flow Metrics can help scrum teams to improve predictability and performance.

Let’s take a closer look at the Flow Metrics in Rally, and how they can help your scrum team to better break down and estimate their stories.

Flow velocity

There are many reasons for high variability on the Flow Velocity chart, and one of them is inconsistent estimation of user stories. If you see a chart with these inconsistencies, it is beneficial to work with the team and revise the estimation process. Specifically, look to address the following topics:

• Does the team have large stories that usually roll over to the next iteration? If yes, suggest an experiment to break them into smaller chunks. This will help with estimation consistency.
• Do they have a good discussion about the story estimations and take into consideration volume, complexity, uncertainty, and knowledge?

Flow time

Flow Time is the lead/cycle time chart, which helps to monitor the cycle/lead time by iterations, months, quarters, weeks, or releases.

How can it help your scrum team to estimate user stories better? If your team is planning for iterations, the stories should fit the iteration. For example, if your iteration is two weeks and the average cycle time for the stories is more than ten days, the team needs to break down the stories into smaller chunks of work. I recommend targeting cycle times less than five days. This means the team slices the work into chunks to deliver customer value more quickly.

In the example below, the team is doing two-week iterations. Most iterations have an average cycle time (from “In Progress” to “Accepted”) of around 10 or fewer days.

Additionally, if the story cycle time is high and the team has many fives and eights in their iteration plan, I recommend working towards story estimates of twos and threes. In the example below, the team has an average cycle time, from “In Progress” to “Accepted,” of around 20 days, and this time increased recently. I would recommend looking deeper into this team’s estimation process to understand how they break down and estimate their stories.

Scatterplot chart (by plan estimate)

This new chart in Rally is extremely helpful as it enables teams to visualize cycle times by story estimations and helps them to see if the estimations are accurate. The Y axis represents cycle time (in days) and the X axis represents the estimated story points.

The Scatterplot Chart (by Plan Estimate), as depicted below, has been created for the same team identified in the Cycle Time chart above. The chart shows all story cycle times during the last three months.

I see that this team has many stories estimated as five and eight and very few stories estimated as one and two. I suggest having the team experiment with trying to break the larger stories into smaller ones to estimate more that are one, two, and three. This will improve flow, deliver value faster, and get customer feedback quicker.

You might also notice five stories, estimated as three, with high cycle times (between 25 and 50 days).  I also see that there is one story, estimated as a five, that has a cycle time greater than 75 days. It’s important to spend extra time on these “outliers.”  Most of these story estimates have cycle times greater than 10 days, which would not achieve the two-week iteration.  

To look deeper, I would check the Cycle Time tab on the Team Board page in Rally:  How much time did these stories spend being “Blocked” and “Ready”?

If they were not blocked and did not stay in “Ready” for an unusually long time, then the stories were probably underestimated.

Here are a few questions I like to ask to better understand how a team is estimating their stories:

• Did the team use a tool like pointing poker to discuss the estimation? Or did one senior team member suggest the estimation for the user story and others just agreed without a conversation?
• Did the team decide on the average estimation, without a discussion?
• Did the team consider complexity, uncertainty, and knowledge, or did they account only for the volume of the work?
• Did the team have a shared understanding of their definition of done/complete?
• Did the user stories have well-defined acceptance criteria?

Conclusion

Flow Metrics are a great resource to leverage for estimating story points. Teams can use this information to guide their story point estimation, and in the process, improve the accuracy of their planning and the execution of their work.

To learn more, I encourage you to explore our Agile Analytics For Digital Transformation educational webinar series. This educational webinar series is intended to help you improve planning, tracking, and forecasting by leveraging a variety of charts and data, such as Burnup and Burndown, Cumulative Flow, Throughput and Cycle Time, and Flow Metrics. This series will demystify common agile metrics and provide practical knowledge so teams are empowered to identify actions for continuous improvement.