Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Guessing Game - Alternatives to Agile Estimation and the #NoEstimates debate - Neil Killick - Agile SG 2013

66a1bb94b08fe5dcd07635a59681626c?s=47 Agile Singapore
November 08, 2013

The Guessing Game - Alternatives to Agile Estimation and the #NoEstimates debate - Neil Killick - Agile SG 2013

Presented in Agile Singapore 2013 Conference

Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

- Should we go ahead with this project? (go/no-go)
- How much will it cost? (bottomline)
- When will it be done? (predictability)
- Should we do project B instead of A? (prioritisation)

This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

Participants will get the following learning outcomes:

- How to reduce the uncertainty and risk inherent with popular estimation models and rituals
- How to determine the price for your customer without estimation rituals
- How to determine delivery dates and roadmaps without estimation rituals
- How to determine which projects to pursue without estimation rituals
- How to do Scrum or XP without estimation rituals
- When, if ever, is it appropriate to estimate software projects?

66a1bb94b08fe5dcd07635a59681626c?s=128

Agile Singapore

November 08, 2013
Tweet

More Decks by Agile Singapore

Other Decks in Business

Transcript

  1. Neil Killick, Agile Coach / Trainer neilkillick.com / iterative.com.au neil_killick

    Copyright Neil Killick, Iterative, 2013 the #NoEstimates debate Alternatives to Agile Estimation and...
  2. WHAT IS Like “Agile”, it has come to have many

    definitions and interpretations. What is #NoEstimates?
  3. A conversation, started on Twitter, about ways in which software

    can be delivered with no estimates. Birth of #NoEstimates
  4. A collection of opinions and practical advice from practitioners who

    deliver software with no estimates. What drove the debate?
  5. A diverse and much needed debate about when it is

    appropriate to use estimates in software, and what form these should take. It’s now become...
  6. Neil Killick Chris Chapman Henri Karhatsu Woody Zuill Vasco Duarte

    The #NoEstimates Crew
  7. WHAT IS EMBRACE AGILE PRINCIPLES FOCUS ON VALUE DELIVER SMALL

    SLICES DELIVER EARLY & FREQUENTLY CUSTOMER COLLABORATION Common Ground
  8. thics mpiricism mergence 3 E’s of #NoEstimates

  9. ETHICS - Cycle of Mistrust Trust breaks down Deliver the

    wrong thing, or late Focus on schedule Commitments of scope and time
  10. EMPIRICISM - Working software allows us to monitor progress and

    manage risk in a new way.
  11. EMERGENCE of cost and value as we get feedback from

    users and market.
  12. Which is more predictable -- A team that estimates or

    one that doesn’t ? Predictability
  13. • DETERMINISTIC AND REACTIVE • FOCUS ON SCHEDULE / PLAN

    • SCOPE DRIVES DECISIONS • LOTS OF WIP IN ATTEMPT TO “GET IT ALL DONE” • NO METRICS, OR INAPPROPRIATE ONES Team #Estimates
  14. High variability 12 days 1 Day

  15. • PROBABILISTIC AND PROACTIVE • FOCUS ON TIME AND CASH

    CONSTRAINTS • ITERATE DESIGN AND DECISIONS • DELIVER WITH FLOW / LIMIT WIP • ACTIONABLE METRICS (e.g. STORY CYCLE TIME DISTRIBUTION) USING A “SLICING HEURISTIC” Team #NoEstimates
  16. Better Predictability 3 days 1 Day

  17. • EXPLICIT POLICY FOR BREAKING DOWN WORK AND MEASURING HOW

    LONG IT TOOK (CYCLE TIME) • STARTS AS A SHARED DEFINITION OF WORK TYPES (e.g. THEME, FEATURE, STORY, etc.) • SLICE ALL UPCOMING WORK SIMPLY AND SYSTEMATICALLY FOR “SMALL-NESS” What’s a “Slicing HeuristicTM”?
  18. • Given Bob is a registered user, When Bob logs

    in Then he should be logged in. • Given Bob is logged in, When Bob chooses Profile Then he should see his profile. Example - Max 1 User Scenario
  19. Slice into 2 separate stories

  20. Slice those stories further

  21. • Agility relies on small chunks, so useful to have

    a consistent and explicit way of creating them • Improve ready-ness and done-ness • Focus on delivering more frequent slices of value • No need to explicitly estimate or re-estimate Why use a Slicing Heuristic?
  22. • Story points are ambiguous, time isn’t • Explicit policy,

    so can be inspected and adapted to narrow control limits • Outliers can be addressed at standup or retro Why use a Slicing Heuristic?
  23. • Exposes goals from solutions and vice versa • Slices

    not necessarily “smaller” than thing we sliced, but multiply our options Slicing creates options
  24. • KEEP TEAMS TOGETHER • ENABLE CONTINUOUS DELIVERY • NO

    LONG PROJECTS / PROJECT THINKING • DRIP FUND (MULTIPLE OPTIONS) • BUILD THINGS ON DEMAND, DELIVER AS SOON AS THEY ARE READY • FLEXIBLE CONTRACTS Portfolio #NoEstimates
  25. Present a business case Approved as viable option Team assigned

    Timeboxed experiment Is initiative still valuable enough? NO Initiative prioritised YES + Team(s) if required Frequent delivery & feedback loop Stop Choosing what to do
  26. Scaling up and down

  27. Questions

  28. What is and isn’t estimating, given people form and act

    on expectations of an uncertain future every day? Question 1
  29. • Estimating = Giving ranges of actual or relative time

    based on past observation, WIP, team size, etc. • Guessing = New teams, with competing priorities, asked to give single dates in unfamiliar domains • There is nothing intrinsically wrong with estimating, so long as we: ◦ Understand its limitations ◦ Use it only in appropriate situations ◦ Don’t rely on it for big up front decision making ◦ Update our estimates (and everyone’s expectations) based on real data frequently Answer 1
  30. Why would we choose not to judge likely outcomes if

    worthwhile human endeavours necessarily carry risk? Question 2
  31. • #NoEstimates is about alternatives to estimating the cost of

    delivering software, not the value it generates • We must hypothesise (estimate) the value of things in order to decide if we will pursue them • My argument is that rather than estimate cost we can control (fix) it in “drips” using fixed Agile teams • Delivery of working software allows us to reassess value iteratively based on the reality of user / stakeholder feedback and market conditions Answer 2
  32. If we elect not to take on the risk of

    predicting an uncertain future, who do we think should, and why? Question 3
  33. • We should embrace the delicious uncertainty of software, be

    excellent in what we do and aim to delight rather than “meet requirements” • Software products and services have ongoing value, so the final cost and value can never be known up front • We can’t fix price and scope, but we can work collaboratively and continuously with our customers to build the best possible result for budget or time constraint • We can provide flexible pricing and termination options to our customers based on similar past work Answer 3
  34. Off the shelf library software costs $50k. We could try

    building our own at $2,500/day but might fail. What should we do? Question 4
  35. • Answer depends on many things like whether we have

    an established team, are we capable of delivering features every few days, etc. • Need to establish the problem rather than decide between solutions; Do we need the software at all? • What are the consequences of spending more than the OTS product costs? Is the $50k a constraint? • How would ongoing maintenance costs compare? Answer 4
  36. • 4 weeks not far into the future, so probably

    have an instant sense of “Is it possible?” and “Can we build something better?” ◦ Do we know enough about the domain? ◦ What are minimum features we need? ◦ How many people do we have? ◦ Do we have any other WIP? Answer 4 (contd)
  37. Neil Killick, Agile Coach / Trainer neilkillick.com / iterative.com.au neil_killick

    Copyright Neil Killick, Iterative, 2013