Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NoEstimates: Forecasting with Less Effort and More Accuracy by Matthew Philip


Published on

Wondering what NoEstimates means in practice or why you would want to try NoEstimates? Perhaps you’ve heard the buzz or read Vasco Duarte’s book. Maybe you simply want to understand how you can spend less time estimating and more time delivering working software—all while providing your customers with some understanding of predictability. If so, this group board game-based workshop will help you understand what and to what degree different factors influence delivery time. Join this session to learn how to move from upfront intuition-based estimates to create a data-based probabilistic forecast that provides a more reliable way to talk about when stuff will be done—and expend less effort to do so. Learn to forecast when things will be done -- with less effort and more accuracy!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

NoEstimates: Forecasting with Less Effort and More Accuracy by Matthew Philip

  1. 1. @mattphilip
  2. 2. Greetings from ST. LOUIS
  3. 3. @mattphilip • Objective: Learn what and how much different factors influence delivery time and understand options for forecasting • Complete cards to deliver the most value! • Play in “day” rounds • Teams play independently but have interdependency with other teams Big Picture
  4. 4. @mattphilip • Cards depict the work needed • Circles represent effort to complete • Work must be started sequentially 
 (no peeking!) • Some cards are urgent! • Some depend on another team The Work
  5. 5. @mattphilip The People • Each person can do 4 points of effort per day. (Use cubes to keep track.) • People can work in areas outside their specialty, but they get only half the points. • If you work on more than one team in a day, you lose one point per extra team 
 (context-switching penalty).
  6. 6. @mattphilip Staff Your Teams! • Divide into teams of 4-8 people – they do not all have to be same size. • Decide as a group each player’s role (wear a “role” name tag). • You can share people across more than one team.
  7. 7. @mattphilip Team Dependency • Some cards have a dependency on another team. • When you start a card that has one, draw a team card to see which team it is dependent upon. • To complete the card, someone from that team must spend time helping you. (Time spent helping another team counts against that person’s capacity.)
  8. 8. @mattphilip Blockers End of Day • For each card in progress, spin (inner ring). • If the card is blocked, place a blocker sticky on the card. Beginning of Next Day For each blocked card, spin (outer ring): • Still blocked: no work can be done on it that day • Unblocked: remove the sticky, continue work
  9. 9. @mattphilip Deployment • When you complete a card’s deployment work, roll the die. • If you roll 1, the card requires rework. Move the card back to Deployment and redo the Deployment work. =
  10. 10. @mattphilip Daily Actions Start a card at any time, and record the commit date Spin to resolve any blocked cards Decide how to use each person’s effort (remember context-switch penalty!) Tick off work on the cards and move them accordingly Roll the die when a card finishes deployment to determine if it deployed, and record the day delivered For each card in progress, spin to determine if it’s blocked Move the day tracker and draw an event card.
  11. 11. @mattphilip Scatterplot Keep track of your delivery times on the scatterplot chart.
  12. 12. @mattphilip Scoring Scoring is based on how long it takes you to deliver each card: • 1-2 days: €700 • 3-5 days: €400 • 6+ days: €300 • Urgent: -€100 per day Before we start, we need an estimate! • Backlog = 25 cards • Average effort per card = 21
  13. 13. @mattphilip After you complete 10 cards: Stop! And ask the facilitator to visit your table. =
  14. 14. @mattphilip Debrief
  15. 15. @mattphilip Do You Assume Correlation? Is the initial sizing a good predictor for when you can get your stuff? In our case, the surprising truth was ”no.” -- Mattias Skarin, Real-World Kanban
  16. 16. @mattphilip What’s Going On? Low process efficiency (typically 5-15% in software delivery) means that even if we nailed the effort estimates … we would be accurately predicting 5-15% of elapsed delivery time! -- Troy Magennis
  17. 17. @mattphilip Sources of Variation • WIP • Technology/domain/product • Team composition • User, client and client representative • Multitasking/focus factor • Market and competitors • System dependencies • Team dependencies • Specialization • Waiting for availability • Rework • Steps/handoffs (50%*50%*50%...) • Stages in team development (Tuckman) • Selection policy • Essential complication (How hard a problem is on its own) • Accidental complication (“How much we suck at our jobs” -Rainsberger)
  18. 18. @mattphilip Straight-line (Average) Forecasts Team A Team B Work item #1 5 days 3 days Work item #2 1 day 3 days Work item #3 3 days 3 days Average 3 days 3 days 3-day delivery time expectancy 66% 100%
  19. 19. @mattphilip Burnups: Straight-line vs. Probabilistic
  20. 20. @mattphilip Uncertainty and Predictability Uncertain != Unpredictable
  21. 21. @mattphilip Vacanti’s Verity When making a forecast (predicting the future), you have to accept that there is more than one possible outcome. Therefore… A forecast is a calculation about the future that includes both a range and a probability of that range occurring.
  22. 22. @mattphilip Vacanti’s Three Instructions 1. Think probabilistically and not deterministically 2. Make short and long term forecasts with the understanding that shorter forecasts will be more accurate than longer ones 3. Reforecast when you get more information
  23. 23. @mattphilip My NoEstimates Manifesto … We have come to value: Probabilistic over Deterministic Delivery time over Development time MVP scope over Full scope Data over Intuition* Reducing sources of variation over Improving estimating That is, while there is value in the items on the right, we value the items on the left more. *Neil Killick uses “empiricism over guesswork”
  24. 24. @mattphilip Better Questions to Ask • “In what context would estimates bring value, and what are we willing to do about it when they don’t?” – Woody Zuill • “How much time do we want to invest in this?” – Matt Wynne • Would we not invest in this work? If not, at what order-of-magnitude estimate would we take that action? • “What can you do to maximize value and reduce risk in planning and delivery?” – Vasco Duarte • Can we build a minimal set of functionality and then learn what else we must build?
  25. 25. @mattphilip References, Tools and More Info • (Vasco Duarte) • (Troy Magennis) • (Dan Vacanti) • (Dimitar Bakardzhiev) • • • • When Will It Be Done? (Dan Vacanti) • • • • •