Senex Rex
  • Team
  • Blog
  • Resources
  • Contact

Bulk Estimation

Posted on April 9, 2012 by Dan Greening Posted in Scrum
Supplier goes over invoices with grocer in bulk foods area of natural grocery
Public domain. USDA Photo by Preston Keres

Estimating lots of work items can help agile teams dramatically: Estimates help Product Owners make trade-offs, help teams gauge capacity, help Product Owner forecast feature releases, and help team members think about architectural issues. However, in too many cases, estimating is painfully boring and slow. It doesn’t have to be.

Why Estimate?

Agile teams use estimates to help Product Owners make trade-offs. If item A is worth $1000 and item B is worth $400, which should we work on? If we don’t know the time items A and B will require, we might think we should work on item A. However, if we know item A will likely take 13 days and item B will likely take 1 day, we’d probably choose to work on item B: We earn $76 per effort-day for item A and $400 per effort-day for item B. There’s more profit having our team invest in item B.

Estimates help teams establish team velocity. Most agile teams estimate effort using a team-specific unit called “story points.” Scrum has a built-in system that correlates actual team-time with estimated effort, called velocity. It is expressed as “story points per sprint,” and is the average sum of the story points from previous sprints.

Estimates help predict the short term future, which can yield higher long-term team velocity. Teams want to limit the work they accept in a Sprint to help focus on work that can be completed. When teams work on more than can be completed in a Sprint, it turns out they end up reducing the agility of the team and the company. A work pattern where teams always start by accepting a maximum of their historic velocity into a new Sprint is called “Yesterday’s Weather”, and has been shown to yield much higher long-term productivity.

Estimates help predict the long-term future. Scrum was developed, in part, to help companies more accurately predict when teams might complete features. If a team reliably completes 15 story points per sprint, a backlog containing 45 story points can likely be completed in 3 sprints. If every Sprint deploys to users, the Product Owner can plan for delivery of all the features in 3 sprints.

Estimation Difficulties

However, long-term forecasts are sensitive to two difficult problems: 1) Teams should have estimated enough backlog items to establish a useful Forecast Horizon, and 2) The estimates should correlate well to team-time, and a few common forms of bias distort those estimates.

Estimation done poorly is painfully boring and slow, so teams don’t want to do it. To get good estimates, Product Owners have to thoughtfully specify what they want to do, so they don’t do it.

Anchor bias presents the biggest danger facing teams estimating stories together. When a person asserts at a team meeting that a backlog item is “easy,” “should only take 2 days” or “is extremely difficult,” this anchoring estimate biases the estimates from other team members. Team members are more likely to assert an estimate close to the anchoring estimate. Anchor bias is typically more pronounced when the anchoring estimator is a leader—such as an accomplished engineer, architect or manager.

Scrum relies on teamwork to complete backlog items. When a leader produces an estimate, it is likely to reflect the biases of the estimator: a high skill level, broad knowledge of the problem, or professional network likely to help overcome problems. But a team cannot productively rely on the leader to do all the work. Less experienced team members are likely to do the work, and therefore their unbiased estimated can have greater utility to the team.

Scrum Poker

To reduce anchor bias, Scrum teams usually rely on a technique called Scrum Poker or Planning Poker. Scrum Poker is based on a technique called “Wideband Delphi Estimation,” developed by Barry Boehm and the Rand Corporation. Here’s how it works:

  1. The Product Owner presents an enabling specification—something that describes the desired outcome or feature from a user’s perspective, typically a user story or a use case—to the team.
  2. The team asks questions to clarify the Product Owner’s specification.
  3. Each team member estimates a Fibonacci number ≥ the amount of work required to complete a feature that satisfies the specification, and keeps it secret.
  4. The ScrumMaster confirms that everyone has selected their secret estimate.
  5. The ScrumMaster says, “Ready, Set, Go,” and all team members simultaneously reveal their estimates.
  6. The ScrumMaster then selects the outliers, and asks them to explain why they selected a low or high estimate. Oftentimes, this inquiry can reveal issues that other team members haven’t considered. For example, a team member might know that freely available code can accelerate development of the feature, and thus chose a lower number. Another team member might have incorporated a Definition of Done that included thorough functional testing, and thus chose a higher number. This discussion can convince others to change their estimates.
  7. The team agrees on an estimate by consensus. If a team member holds out, the maximum number expressed is the estimate for the backlog item.

The Product Owner and ScrumMaster can accelerate Scrum Poker by creating good enabling specifications, before the team meets. If the enabling specifications in the backlog item are incomplete or confusing, Scrum Poker can take a lot of time. By involving architects, user experience designers and operations engineers before a team meeting, the Product Owner and ScrumMaster can provide clearer specifications. And clearer specifications can lead to faster estimation. When multiplied by the number of team members in a meeting, this usually results in substantial cost savings.

One thing to remember: brevity can lead to greater clarity. Shorter specifications are more likely to be thoroughly read by team members.

Bulk Scrum Poker

In it’s standard form, each item is estimated individually. But if a team has a large number of backlog items to estimate, they can be estimated much faster in bulk, with a technique I call Bulk Scrum Poker. I have seen teams estimate 80 stories in 90 minutes this way.

1. Print Stories
Bulk Estimation-01

Create a complete set of stories reflecting the release you want to forecast. Consider using a definition of Project Ready to ensure that you’ve considered all major risks. Put these in canonical story form, “As a <stakeholder>, I can <accomplish something>, so <business value accrues>.” Print each story on a separate page.

2. Discuss Stories

Bulk Estimation-02

Spread all the stories out on a table or the floor, so all the stories are visible. Bring the product owner and all members of the development team together in the room. Let everyone know that the development team will be silently estimating the stories, but before that estimation they can ask the product owner to clarify the meaning of the different stories. Caution everyone not to use language that introduces anchor-bias, such as, “Isn’t this story really easy?” Provide at least 30 minutes for this step. If people are not asking questions, quiz them to ensure they have considered the stories. When questions have stopped, go to the next step.

3. Silently Rank
Bulk Estimation-03

Have the team silently rank order stories in rough order of difficulty, from left to right. Stories on the left should be easy to complete. Stories on the right should be difficult or time-consuming. If team members think a story cannot be responsibly estimated—because there is not enough information or because there are significant implementation risks—team members should put it at the furthest right. If there are conflicts during ranking, such as that one person tries to put a single story further left and another further right, the outcome should place the story toward the right and they should pull the story out or mark it “to be discussed”.

4. Discuss Ranking

During the previous step, some stories will have generate conflict and questions. Let people ask questions and discuss conflicts. Why do people feel that some stories cannot be responsibly estimated? Can those stories be rewritten now to make them easier to estimate? Why do people differ in their assessment of a story’s difficulty? Can those differences be resolved? Rerank stories based on these discussions. There’s no need to be silent during this time.

5. Silently ClusterBulk Estimation-4

Have the team silently cluster the stories into 5 or 6 piles, so that each pile contains stories that are roughly the same difficulty. Keep the ranking, so all stories in a particular pile are easier than the stories in the pile just to its right.

6. Revise Stories
Bulk Estimation-05

During the previous step, team members may have disagreed. Talk about those disagreements. Are there stories that belong in a different pile? Take another look at the stories on the far right? Is there anything that can be done now to change or split those stories so they can be estimated? If the team can agree, create new stories or rewrite existing ones as needed and put the changed stories in the most appropriate piles.

7. Estimate Third Pile
Bulk Estimation-06

Has the team worked together before? Does it have a set of reference stories from the past which can help it estimate consistently with its past? If not, assign 8 to all the stories in the third pile from the left, and write “8” on all stories in that pile.

If the team has previously estimated stories together or has reference stories, have the team play Scrum Poker on the third pile, saying this, “Thinking about all the stories in this pile, and considering the most difficult story in the pile, secretly pick a Fibonacci number equal-to or greater-than the the effort required to complete that story.” When all team members are ready, have all team members reveal their numbers. The outliers are the stars of the show. Ask the person who picked the highest number and the person who picked the lowest to justify their estimate. Then discuss among the team. If people want to change their estimates to agree on a single number, take that number as the estimate. Some teams like to play another Scrum Estimation game to find this number. Write that number on all the stories in the third pile.

8. Estimate Stories on Left

Bulk Estimation-07

Consider the stories in the second pile. Which story is the most time-consuming or difficult? Use the most difficult story in the third pile and the estimate written on it as a reference story, and estimate that most difficult story in the second pile using Scrum Estimation.

9. Estimate Stories on Right
Bulk Estimation-08

Then estimate stories on the right, again using Scrum Poker.

A large number of stories should now have estimates.

References

Boehm, B. W. 1981. Software engineering economics. New Jersey: Prentice-Hall.

James Grenning, “Planning Poker or How to avoid analysis paralysis while release planning,” (April 2002).

James Grenning, “Planning Poker Party (The Companion Games),” 2 March 2009.

Share this:

  • Click to print (Opens in new window)
  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Reddit (Opens in new window)
  • Click to email a link to a friend (Opens in new window)
  • More
  • Click to share on Tumblr (Opens in new window)
  • Click to share on Pinterest (Opens in new window)
  • Click to share on Pocket (Opens in new window)
« Agile Abandonment 2: Root Causes
Enterprise Scrum Thinking: Part 1 of 3 »

Leave a comment Cancel reply

You must be logged in to post a comment.

Continue with Facebook
Continue with LinkedIn

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Pages

  • 5 Points
  • Account
  • Agile Capitalization
  • Agile Capitalization Video: Greening and Rudd
  • Agile Training
  • Agility Language
  • Call for Papers: Agile/Lean at HICSS (Kauai, January 5-8, 2016)
  • Call for Papers: Agile/Lean at HICSS
    (due June 15, 2016)
  • Certified Enterprise Coaching
  • Clients
  • Contact Us
  • Courses: Agile Capitalization Workshop
  • Courses: Agile Development
  • Courses: Agile Product Management
  • Courses: Executive Introduction to Agile
  • Courses: [email protected] Practitioner
  • Dan R. Greening
  • Enterprise Scrum: Scaling Scrum to the Executive Level
  • Glossary
  • Home
  • Jeff McKenna
  • John Horton
  • Kay Lynn Gabaldon
  • Login
  • Logout
  • Members
  • Password Reset
  • Premium Content
  • Premium Content 2
  • Privacy Policy
  • Register
  • Release Duration and Enterprise Agility
  • Resources
  • Rob Myers
  • Senex Rex Team
  • Short Course: Agile Manager
  • Sign up for Premium Content
  • Software Moneyball
  • Subscribe
  • The First of Five Challenges to Large Organizations that Force Agility
  • Troy Magennis
  • User
  • Vincent T. Mills
  • Senex Rex Blog Posts
  • Rapid Agile Forecasting

Archives

  • August 2018
  • February 2018
  • February 2017
  • March 2016
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • February 2015
  • August 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • April 2012
  • March 2012
  • December 2011
  • July 2011
  • March 2011
  • February 2011
  • September 2010
  • August 2010
  • May 2010
  • April 2010
  • March 2010
  • January 2010
  • May 2009
  • March 2009

Categories

  • Advocacy (11)
  • Agility (10)
    • Agile Base Patterns (7)
  • Calls for Papers (4)
  • Enterprise (23)
  • Events (5)
  • Job Search (1)
  • Marketing (2)
  • Metrics (12)
  • Personal (7)
  • Personal Improvement (2)
  • Portfolio Management (11)
  • Product Management (9)
  • Quality (6)
  • Scrum (31)
  • Software (4)
  • Training (2)
  • Uncategorized (5)

WordPress

  • Log in
  • WordPress

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Pages

  • 5 Points
  • Account
  • Agile Capitalization
  • Agile Capitalization Video: Greening and Rudd
  • Agile Training
  • Agility Language
  • Call for Papers: Agile/Lean at HICSS (Kauai, January 5-8, 2016)
  • Call for Papers: Agile/Lean at HICSS
    (due June 15, 2016)
  • Certified Enterprise Coaching
  • Clients
  • Contact Us
  • Courses: Agile Capitalization Workshop
  • Courses: Agile Development
  • Courses: Agile Product Management
  • Courses: Executive Introduction to Agile
  • Courses: [email protected] Practitioner
  • Dan R. Greening
  • Enterprise Scrum: Scaling Scrum to the Executive Level
  • Glossary
  • Home
  • Jeff McKenna
  • John Horton
  • Kay Lynn Gabaldon
  • Login
  • Logout
  • Members
  • Password Reset
  • Premium Content
  • Premium Content 2
  • Privacy Policy
  • Register
  • Release Duration and Enterprise Agility
  • Resources
  • Rob Myers
  • Senex Rex Team
  • Short Course: Agile Manager
  • Sign up for Premium Content
  • Software Moneyball
  • Subscribe
  • The First of Five Challenges to Large Organizations that Force Agility
  • Troy Magennis
  • User
  • Vincent T. Mills
  • Senex Rex Blog Posts
  • Rapid Agile Forecasting

Archives

  • August 2018
  • February 2018
  • February 2017
  • March 2016
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • February 2015
  • August 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • April 2012
  • March 2012
  • December 2011
  • July 2011
  • March 2011
  • February 2011
  • September 2010
  • August 2010
  • May 2010
  • April 2010
  • March 2010
  • January 2010
  • May 2009
  • March 2009

Categories

  • Advocacy (11)
  • Agility (10)
    • Agile Base Patterns (7)
  • Calls for Papers (4)
  • Enterprise (23)
  • Events (5)
  • Job Search (1)
  • Marketing (2)
  • Metrics (12)
  • Personal (7)
  • Personal Improvement (2)
  • Portfolio Management (11)
  • Product Management (9)
  • Quality (6)
  • Scrum (31)
  • Software (4)
  • Training (2)
  • Uncategorized (5)

WordPress

  • Log in
  • WordPress
Copyright ©2013-2015 Senex Rex LLC. All Rights Reserved.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Do not sell my personal information.
Cookie SettingsAccept
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDurationDescription
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
SAVE & ACCEPT