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?

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