How to Estimate the Effort for Product Backlog Items in Scrum

How to Estimate the Effort for Product Backlog Items in Scrum

In Scrum, the effort of the work to be performed is estimated before each Sprint. This is not explicitly stated in the Scrum Guide, but it is best practice. In this article you will learn why you should estimate the effort of the backlog items and how to conduct the estimation meeting. But you also learn that not only does the estimated size as a result add value to this activity, but that the estimation activity itself has other relevant benefits. Read on and learn something more!

Why You Should Estimate the Effort

You might be surprised, the Scrum Guide doesn’t mention the topic of estimating effort. But that doesn’t mean that the Backlog Items for the planned Sprint should not be estimated. Most Scrum teams make an effort estimate so they know how much work they can accomplish in a Sprint, while other Scrum teams just use their best estimate based on empirical experience from the previous Sprint(s)—or don’t estimate at all.

A Product Backlog without estimates is not transparent. There are at least five reasons why estimates are important:

  • to coordinate dependencies
  • to align priorities
  • to determine the option with the optimal value
  • to forecast deliveries
  • to form a shared understanding

Often, the simplest estimation method for these five areas is enough to make things fairly transparent. To me an additional value of estimating is the discussion among the team members that takes place when they try to agree on a size. The thoughtful and at times vigorous debate among the people who actually will do the work result in shared clarity.

In the next sections, I show you why it makes sense to estimate at two levels, explain the Estimation Meeting, and two well-known estimation methods that have proven to make estimation very efficient.

Effort Estimation on Two Levels

At Scrum, you estimate the effort on two levels: the Backlog Item level and the task level. To get good and reliable estimates, the whole Scrum Team should always be present at the Estimation Meeting. If activities are estimated, the Product Owner is not absolutely necessary.

1. Effort Estimation at the Backlog Item Level

Before starting the first Sprint, you should estimate as many backlog items as possible so that you can create a release plan or medium-term planning. The more backlog items you have estimated, the further into the future you can plan releases.

Most Scrum Teams use story points for this estimate. It is estimated in the Estimation Meeting. Then the first Sprint starts with the Sprint Planning.

2. Effort Estimation at Task Level

As soon as the tasks for the implementation of the Backlog Items are determined in Sprint Planning, their effort is also determined. Tasks should not be estimated in story points or task points, but in hours and it is the effort that the entire team needs for the tasks.

The Estimation Meeting

The Estimation Meeting (also called “Backlog Refinement Meeting”) is the planning meeting with the Product Owner to get clarity for the next Sprint and the subsequent ones. Activities in the meeting are:

  • Clarifying details of Backlog Items (most often Stories)
  • Detailing Backlog Items
  • Estimating the effort of Backlog Items
  • Checking the prioritization of Backlog Items
  •  Receiving feedback from the team about the Backlog Items

The Estimation Meeting should also give the Developers a certain security and perspective for the future Sprints.

The Product Backlog changes during the entire project duration. New Backlog Items are added, and existing ones are adjusted or omitted. Therefore, it is the task of the Product Owner to provide a current, estimated and prioritized Product Backlog for each Sprint planning. To do this, an estimation meeting is always held before the Sprint planning. The following figure shows you when the Estimation Meeting is scheduled to take place.

Scrum Events Timeline
The Estimation Meeting before the Sprint Planning

The Purpose of the Estimation Meeting

1.  Backlog Grooming/Refinement:

  • The Product Owner discusses the Backlog Items, which they intend to implement in the next Sprint or in the following Sprints with the Developers.
  • Epics and large Backlog Items are broken down into smaller Items so that they can be implemented in the Sprint.
  • Some Backlog Items are completely removed from the Product Backlog when their effort and benefit no longer match or when there is no longer a need.
  • The Developers provide feedback for the Product Owner regarding feasibility, technical requirements and dependencies.

2.  Estimation:

  • The effort is determined for the changed and new user stories
  • If necessary, stories that are too big are broken up further.

The estimation meeting is primarily used to prepare for the Sprint Planning. This ensures that all effort estimations are already available and that the Developers already know the user stories that will be implemented. If a longer discussion is necessary for new user stories, then the Scrum Master postpones them to a separate meeting.

The meeting is also intended to inform the Developers about future stories and to gather feedback.

Participants, Organization and the Process of the Estimation Meeting

The whole Scrum Team takes part in the Estimation Meeting. It may also make sense to call in external specialists (e.g. system architects, database Developers or members of the specialist department). As a facilitator, the Scrum Master ensures a smooth process.

I recommend holding the Estimation Meetings about two days before the next Sprint Planning. Then the Product Owner can check the prioritization and the release plan up to Sprint planning and adjust them if necessary. It has proven useful to hold the Estimation Meeting directly after a Daily Scrum, so that the daily routine of the Developers is not interrupted or disturbed again by a meeting. For a 4-week Sprint, the meeting should not take more than 2-3 hours. There are also Scrum Teams that perform the Estimation Meeting twice per Sprint or weekly, but then it is much shorter. According to the Scrum Guide, the Estimation Meeting (Refinement) should not take up more than 10% of the Development Team’s capacity.

Who Estimates Backlog Items?

An important principle at Scrum is: Only the Developers estimate, i.e., those who are responsible for the implementation of the Backlog Items (e.g. User Stories). The Scrum Master can also estimate if they have the technical understanding and the Developers invite them to do so. Note that all Developers should always be present when estimating!

At the Estimation Meeting, the Product Owner explains the requirements and answers questions. The Developers estimate and the Scrum Master facilitates and ensures that the meeting is completed on time.

The Benefits of the Estimation Meeting

In addition to estimating the effort of Backlog Items, the Estimation Meeting has several other important benefits:

  • The Product Owner receives additional help to optimize the Product Backlog
  • Knowledge is passed on to all project participants
  • The Product Backlog contains only relevant items
  • Questions and uncertainties can be clarified quickly (the “WHAT” is clarified)
  • Sprint planning can be prepared (only the “HOW” has to be clarified then)
  • Risks are reduced because the backlog is discussed before Sprint planning

In this article, you’ll learn how to estimate with points and learn about the two most popular estimation methods in Agile Project Management: Planning Poker and Magic Estimation.

More about the different Product Backlog items: What Are Epics, Features, User Stories and Tasks in Agile Project Management?

Here You Can Find More Knowledge

Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!

Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!

Posted in Agile Project Management.