Estimating in Scrum – Why & How To

Estimates are a fundamental element of Scrum. Because they are the basis for planning and predicting when work will be completed. Like Sprints, if you’re not using Sprints and estimating, then you’re not using the Scrum framework.

Learn More:

• Official Scrum Guide.
• About the Best Scrum Handbook – Agile Project Management For Dummies.
• Scrum Alliance.
• Atlassian’s Jira.
• Microsoft’s Azure DevOps – Formerly Known As: Visual Studio Team Services (FKA: VSTS).
• Computer Associates’ (CA) Rally.
• Sprint Burndown in Atlassian’s Jira is described in Jira Burndown Chart Tutorial.
• Sprint Burndown in Microsoft’s Azure DevOps (FKA: VSTS) is described in Monitor sprint burndown.
• Release Burndown in Microsoft’s Azure DevOps (FKA: VSTS) is described in Configure a Burndown or Burnup widget.
• Release Burndown chart from Atlassian’s Jira is described in Jira Versions Tutorial.
• How to Read a Burndown Chart from CA’s Rally documentation has some good tips that are similar to what you might learn in a certified Scrum Alliance class.
• Release & Iteration Burndown from CA’s Rally documentation.

How To Use Estimates:

Estimates are used for the following:

• Sprint planning, release planning and other types of planning.
• Real time progress tracking and reporting.
• Predictions on when work will be completed.

Here are some of the ways that estimates are used in Scrum.

Sprint Planning & Executing:

Estimating Story Points and Task hours are essential parts of creating a Sprint Plan. Estimates are used in the following ways in Sprint Planning:

• The estimates are compared against the Scrum team’s Sprint capacity (available time to work), to ensure the Sprint Plan can be completed.
• Estimates and completion status are used to create a Sprint Burndown chart. This chart is used to track and report on progress and status in real time.
• The Sprint Burndown can be used to diagnose execution problems immediately, and allow the Scrum team to adjust in real time so they are more likely to complete their Sprint Plan.

The following is an example Sprint Burndown chart from Atlassian’s Jira. You can learn more about this in Jira Burndown Chart Tutorial.

Sprint Burndown in Jira based on Story Points

Here are some of the key components of the Sprint Burndown.

1. Story Points: This estimation statistic is the measurement or field your choose to base the chart on and is configurable in Jira.
2. Remaining Values: The red line represents the total amount of work left in the Sprint, according to your team’s estimates.
3. Guideline: The grey line shows an approximation of where your team should be, assuming linear progress.

Here is an example of a Sprint Burndown in Microsoft’s Azure DevOps (FKA: VSTS). You can learn more about this in Monitor sprint burndown. This Sprint Burndown chart is based on Task time and status data, specifically the Remaining Work field and workflow status, which must be updated by team members in real time as work is completed, otherwise the chart will be inaccurate and useless.

Sprint Burndown in Azure DevOps based on Task Hours (Remaining Work)

A few ways to use the Sprint Burndown chart:

• IF the red Remaining Values line is below the grey Guideline, THEN your Scrum team is on track to completing all their work by the end of the Sprint.
• IF the red Remaining Values line is above the grey Guideline, THEN your team is predicted to not complete all the work in the Sprint Plan.
• IF the red Remaining Values line is well below the grey Guideline, THEN your Scrum team might be able to add more work to the Sprint Plan and complete more work than they originally planned.

How to Read a Burndown Chart from CA’s Rally documentation has some good tips that are similar to what you might learn in a certified Scrum Alliance class.

Measuring Sprint Plan Accuracy Over Time:

Equipped with estimates and data on work completed, you can gain the following insights:

• By comparing Story Points planned in each Sprint, against the Points completed in each Sprint, you can measure how accurately the Scrum team is planning their Sprints.
• How much work, measured in Story Points, they can complete in a Sprint. This is known as Velocity.
• By comparing the Story Point estimates in the Product Backlog, against the Sprint Velocity, you can predict when work might be completed over the long term.

An Important Note About Velocity:

Some think that Velocity is a way to measure and compare different teams to each other. It is not. That is because Velocity is subject, because it’s calculated from Story Points, which themselves are also subjective. In other words Points, and therefore Velocity, are only meaning to the Scrum team using them. The are NOT meaning outside of the team.

This is by design in the Scrum framework, because the meaning of points is defined by the team using them. The meaning of points cannot, and should not, be defined by someone or some entity outside of the team. In other words, points cannot and should not be standardized. This is because, that just does not work, and that is why it would also violate an essential organizing principle of Scrum.

As expressed in the official Scrum Guide.

In The Scrum Team section on page 6 of the Nov 2017 revision PDF:

“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”

In The Development Team section on page 7 of the Nov 2017 revision PDF:

“Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”
“Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”

A Better Way to Measure Teams Than Velocity:

Since Velocity has no objective meaning outside of the Scrum team, what does ? How accurately teams are planning and executing their Sprints.

To measure that, simply compare the Story Points planning to the Points completed, with an objective measurement. This simple formula does just that, and you can call it Planning Precision %. It is easy to interpret when the result is formatted as a percentage.

Planning Precision % = (Completed Points / Planned Points ) – 1

Because this calculation removes specific point values from the measurement, unlike velocity, it is an objective measurement of how precisely Scrum team’s are planning and executing their Sprints.

Here’s a mockup of how Planning Precision %, displaying it formatted as a percentage, might be reported on with a Business Intelligence (BI) or other reporting tool.

Planning Precision % Reporting Mockup

How to interpret Planning Precision %:

• 0% is a perfect measurement. IE. The Scrum team planned 50 points and completed 50 points – (50/50) – 1 = 0%
• –10% would result if the team planned 50 points but completed 45.  (45/50) – 1 = -.10 or -10% when formatted as a percentage.
• A lower percentage – or + is better.
• A negative percent = completed less than planned.
• A positive percent = completed more than planned.

Longer Term Predictions:

If a Scrum teams estimates Stories in their Product Backlog further out beyond just 1 Sprint, they will have the numerical data on which to make more accurate predictions. For example, estimating all of the backlog that composes a release, or planning periods based on months or quarters.

Longer term predictions can then be made, based on Story Point estimates of a Product Backlog, compared to how many Story Points of work are being completed in Sprints, or the Scrum team’s Velocity.

For example:

• IF all of the Product Backlog work to complete a release = 500 points.
• AND the Scrum team’s Velocity (Points completed each 2 week Sprint) = 50.
• THEN it might take 10 Sprints, or 20 weeks, to complete the release.

By measuring and managing this over time:

• Progress and status can be reported on automatically and in real time.
• Adjustments to planned release scope and estimates can be made in real time, informed by detailed data.
• Release goals and time frames are more likely to be met.

Release Burndown Charts:

The following is an example Release Burndown chart from Atlassian’s Jira. You can learn more about this in Jira Versions Tutorial.

Release Burndown in Jira

Here are some of the key components of the Release Burndown. In this example, the work is measured in Story Points.

1. Release: Pulldown menu allows you to select a version (release).
2. Work added: The dark blue segment shows the amount of work added to the release in each Sprint.
3. Work remaining: The light blue segment shows the amount of work remaining in the release.
4. Work completed: The green segment represents how much work is completed for the release in each Sprint.
5. Projected completion: The report projects how many Sprints it will take to complete the release, based on the team’s Velocity.

Here’s an example of a Release Burndown in Microsoft’s Azure DevOps (FKA: VSTS). You can learn more about this in Configure a Burndown or Burnup widget.

Release Burndown in Azure DevOps

Scrum Guidelines for Estimating:

When considering estimating techniques it’s helpful to ground the discussion with the guidelines that the Scrum framework offers.

Estimating in Sprint Planning:

In the Sprint Planning meeting there are 2 parts.

Different Scrum framework learning sources use different terms for these 2 parts/topics/phases.

• The Scrum Guide in the Sprint Planning section on page 10 of the Nov 2017 revision, refers to them as topics.
• The Agile PM Book, Chapter 8: Planning Releases and Sprints > Sprint planning – page 155, Kindle location 3623, refers to them as parts.
• And certified Scrum Alliance training refers to them as phases. I’ll go with calling them parts.

Here is a brief list of the typical activities for each part.

Part 1 – Set the Goal and Select Stories:

1. Set Sprint Goal.
2. Select Stories from the Product Backlog.
3. Revisit & refine the Story Point estimates.

Part 2 – Break Down Stories into Tasks:

1. Break Stories down into Tasks.
2. Estimate each Task in person hours.

How estimates are measured:

Measuring Stories:

The Scrum guideline for estimating Stories are Story Points that measure effort. Effort is a measurement of how easy or difficult it is to complete the work in order to fulfill the requirements in the Story. Effort is NOT a measurement of person time to complete the work.

Story Points are numbers that are selected from the Fibonacci number sequence. The Fibonacci sequences of numbers are 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 and on and on. Each number, after 2, is the sum of the previous two numbers.

There are several techniques for estimating Story Points, including estimation poker or planning poker, affinity estimating, t-shirt sizing and others.

Scrum teams using Agile Lifecycle Management tools, such as Atlassian’s Jira, Computer Associates’ (CA)Rally, Microsoft’s Azure DevOps (FKA: VSTS), and others, typically use multiple types of backlog work items or issues. This applies to any other work item or issue types that you may be using, that are at the same level of the backlog hierarchy as are Stories, such as bugs, action items, etc.

Measuring Tasks:

The Scrum guideline for estimating Tasks is person hours. And Task breakdowns are only done immediately before the Sprint begins, during Sprint Planning. So you would never have tasks and time estimates for future Sprints nor for a Product Backlog.

Task breakdowns and person hour time estimates help the Scrum team to validate their Sprint Plan. They can use the task hours to decide whether the time required to work on tasks is less than the time available in the Sprint. If the total person hours of the tasks exceeds the hours available, then the team can remove Stories from the Sprint Plan, or break the Stories down into smaller Stories, so that their Sprint Plan can be completed.

As the Sprint work progresses, the Scrum team can continuously compare their progress based on task hours, every day. And make informed adjustments, before they go so far off the Sprint Plan that they cannot complete it.

The lessons learned from tasks and hour estimates, also helps inform and improve the accuracy of future Sprint Plans, and Story level estimates too.

Measuring Sprint Capacity:

To validate whether the Sprint Plan can be completed, the task hour estimates, and day to day progress, needs to be measured against the team’s Sprint capacity. Capacity is simply a measurement of how many hours each team member has available.

A good guideline for Sprint capacity is described in the Agile PM Book, Chapter 8: Planning Releases and Sprints > Sprint planning > The sprint planning meeting > Part 2 > Tip – page 162, Kindle location 3768. In a 2 week Sprint, assume that 9 working days are available – 9 days removes the time spent on non-development activities. And each team member has 7 productive hours per day. That equals 63 hours (7 hours × 9 days).

Who Creates the Estimates ?

In the official Scrum Guide in the Product Backlog section on page 15 of the Nov 2017 revision PDF:

“The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.”

So it’s very well established, in the Scrum Guide, in certified Scrum Alliance training and in the Agile PM Book, that the Development Team creates the estimates and has the final decision on the estimates.

Common Compromises of Scrum Guidelines for Estimating:

Sprint Planning Part 2, the task break downs and time estimates, is sometimes skipped. Especially by teams that are new to Scrum. The reasons often given are:

• We don’t have time for that.
• It’s too much overhead work and a waste of time.
• We don’t need to plan that much.
• We are too busy developing to do planning.
• (fill in your fav)

Advantages:

The advantage to compromising on estimating is often expressed, in one way or another, as essentially:
– It saves time.

Disadvantages:

• Not precise.
• Can’t validate the Sprint Plan with task break downs and hour estimates.
• Without task detail, the team cannot see daily progress as clearly and see problems sooner so they can act on them and adjust the Sprint Plan.

T-Shirt Sizes = Story Size:

Each Story is given a t-shirt size. T-shirt sizes are typically expressed as:

• XS = eXtra Small
• S = Small
• M = Medium
• L = Large
• XL = eXtra Large

Disadvantages:

• No numbers. You need numbers to total things and for predictions.
• Not precise.
• Very subjective. Each person may define differently, what each size means to them.

Story Points = Range of Person Days or T-shirt Size:

This is where the Fibonacci number sequence ( 1, 2, 3, 5, 8, 13… ) is used, but each number represents some agreed upon range of person days, or worse just a t-shirt size.

Disadvantages:

• Subjective, because it lacks the task level details and hour estimates to validate it.
• No way to sum up time estimate in person days, because:
  1. Person days are not stored with the Story but instead are in a separate reference spot, like a wiki page or spreadsheet, that is usually a table that relates each point value to range of person days.
  2. Using a range of person days, and not a specific number.

Story Points = Person Days:

Good Practices:

• Story Points = Person Days
  • For example:  1 Story Point = 1 Person Day of Work ; 2.5 Story Points = 2.5 Person Days, etc.
• 1 Person – 1 Story
  • Only the person doing the work should estimate it.
  • To keep it simple and quick, only 1 person should work on each Story.  This is a good practice, since Tasks with hour estimates are not being used.  Tasks would allow multiple people to be assigned work under 1 Story, and so without Tasks with hour estimates on them, 1 person – 1 Story is a better practice.
  • So that it is clear (transparent) as to who is doing the estimate, assign them to the Story.
  • If the assignment must later change, then that new person assigned should re-estimate the Story.
• Estimates can be precise.
  • Be as precise as the person doing the work, is confident in estimating.
  • Since a time based measurement is being used, relative sizing techniques such as using the Fibonacci number sequence of 1, 2, 3, 5, 8, 13, etc. do not add value, but instead take value away because precision would be lost.
• Stories should be broken down in to small pieces.
  • No bigger than 2 person days of work is a good rule of thumb.
  • If the Stories are too big, then progress will not be visible on the Sprint Burndown, and in other reporting, for some time after the Story work begins.
  • Big Stories will not burn down until the Story is Done.  And so you will not see progress in a timely way.
  • This would interfere with transparency, and therefore making it much more difficult to make timely corrections before the team risks not completing their Sprint Plan.
• Limit the WIP.
  • Keep the Work In Progress (WIP) to an absolute minimum.
  • 1-2 Stories In Progress per person at the same time, is a good rule of thumb.
  • Just 1 WIP per person is ideal, regardless of framework or technique being used.
  • If too many Stories are WIP, then the same problems with transparency and progress reporting will occur.

Disadvantages:

• Lacks the precision of task break downs with hour estimates.

Advantages Over Other Compromises:

• More precise than other compromises. But not as precise as task hour estimates.
• Can be summed.
• Can be compared to Sprint Capacity.
• Points are clearly relatable to time. So if the Stories are broken down into smaller pieces, then progress is more easily measured and problems easier to see and therefore fix.
• Transparency is better than other compromises, because everyone can easily see a number that relates to time.
• Can be used as an interim step towards Scrum good practice, to do task break downs with hour estimates. Once that good practice is adopted, the meaning of points can be changed to measure effort as defined by Scrum guidelines.