David Crosby www.atomicobject.com Time-Based Estimates Are For Suckers! (Size-based is The Way to Go) Monday, May 6, 13 Hi everyone, thanks for coming I am David Crosby from Atomic Object I’d like to talk about how we estimate software projects using size-based estimation aka Relative Complexity estimates I’ve done this for quite a while But though I’ve internalized I have recently been helping share and teach the technique to some newcomers to Atomic. It’s still fun. Takes some convincing, practice, faith. 

@atomicobject http://spin.atomicobject.com Don’t get suckered into estimating time. 2 Monday, May 6, 13 So why the title? Because time-based estimation is common. It seems easy. attractive We are the suckers, simple logic: - we’re asked about time - we answer in time Then we under-estimate finer details Start thinking about tasks rather than features Progress hard to measure, velocity is strange and jumpy can't improve estimates with measured knowledge Generally, Easy to start ignoring data, hard to make good use of it There are Dangers to be avoided! Rewards to be reaped! by using size-based 

@atomicobject http://spin.atomicobject.com Please read. 3 Monday, May 6, 13 This book is still my favorite for reading about the Why and How of making estimates. Also includes cool applications of our estimates in the Planning segments. This is where you should start reading. 

@atomicobject http://spin.atomicobject.com 4 I want you to make the switch. Monday, May 6, 13 How many here use size-based est regularly? MY goal is to get you to switch over to size-based estimation: - reviewing how it works - some some adoption challenges, and tips and tools you can use - illustrating the value you can extract from the process - hitting some common questions challenges (at the team and business level) 

@atomicobject http://spin.atomicobject.com Desirables 5 • Build a plan, schedule • Derive time and cost estimates from data • Capture and reduce uncertainty • Anticipate and allow for change • Continuously improve estimates over time Monday, May 6, 13 Stuff we want to be able to do. Whatever approach we take to project management, these are some good things to want. My irritation with time-based is: hard to get these things. Size-based unlocks these BUT you’ve got to get started. There are some up-front challenges. Lemme try to address those and provide encouragement. 

@atomicobject http://spin.atomicobject.com Three Challenges 6 • Breaking things down by value, not by task • Thinking in terms of “size” • Making estimates Monday, May 6, 13 Some things I find challenging for myself, and when training others. 

@atomicobject http://spin.atomicobject.com 7 Breakdown -> Stories Monday, May 6, 13 Let’s talk (briefly) about breaking down work items. Assuming you’ve got a broadly-defined product, maybe some release planning. (Feature Map, Product Backbone... something to draw on) User stories are a good way to do this. - Not just another word for task. (Tasks are something we do to complete Stories) - Stories constrain you to considering what has value, what you can deliver, how the customer will verify. - Can be challenging - Must measure something that matters Small enough to get a few done per iteration Big enough to be real, so the customer can speak about them. Key: DISCREET ITEMS OF DELIVERABLE VALUE Don’t worry just yet how big they are. 

@atomicobject http://spin.atomicobject.com 8 Thinking about “Size” Monday, May 6, 13 The next challenge for me has always been thinking in terms of size. Might help to separate the concept of “time” into “size” and “duration”. We’ll come back to “duration”. Size. Complexity. Difficulty. How do I estimate that? Lots of words - Big. Difficult. Involved. Small. Quick. No-brainer. BUT no numbers Eg. Painting some rooms: - basic idea is simple - details are complicated - if we start comparing rooms, we might agree that one is half again as large as another, or 5 times bigger, or whatever “Agree” -- we’re not doing this alone. We need to have some consensus Runners looking down a trail. If we all agree we’re just comparing relative size pick a number scale for this team, on this project 

@atomicobject http://spin.atomicobject.com 9 Estimating Monday, May 6, 13 Challenge #3 Get those numbers onto the story cards. Eeep! First few are notoriously hard; nothing to relate to! Pick some stories that you loosely plan to deliver soon. Just plunk down some numbers. Come back later and adjust. Difficulty: bogged down deciding between 1 and 2 and 3, or 8 and 9. Choice overload: what’s the difference between 1 and 9? 12 and 13? Start to feel like just making stuff up. Constraints might help... 

@atomicobject http://spin.atomicobject.com 10 Powers of Two 1,2,4,8,16... Monday, May 6, 13 Let’s restrict ourselves to picking from the powers of 2 starting with 1. Reduces the number of reasonable choices -- easier bucket selection. above 16 it’s hard to “feel” what the values really mean in real life. We start to find ourselves “liking” the 1,2,4 estimates more than the 8+, because we feel more confident on the low end of the scale. (We suspect this will affect our tendencies when breaking down stories in the future.) Getting into the bigger numbers makes us feel nervous and uncertain. (Our customers will certainly want to know how to de-risk those) *Epic: we’ll see later Next question: how to get the team settling on the actual choice? 

@atomicobject http://spin.atomicobject.com 11 Planning Poker Monday, May 6, 13 Answer: planning poker. The team sits around a table considering a story at a time. Preliminary discussion on the meaning of the card. Everyone holds a hand of cards marked 1,2,4,8,16,32, makes a secret selection, “One, to, three, show” -> all reveal Review the estimates, discuss reasons for highest and lowest, resolve as a team the final choice. (Recall this is an estimate of difficulty for any person or pair on the team, not the fastest, most-knowledgeable) Lots of discussion, questions etc are generated. Further decomposition may occur. Result: a body of relative-size estimates, well-understood by (and agreed to by) all team members. 

@atomicobject http://spin.atomicobject.com 12 *Epics Monday, May 6, 13 “huge stories” Represent large functional areas that need to be broken down more to be understood Large scary estimates - capture uncertainty, inflate budget, look like barriers Draw attention, make us worry (but also let us move on with the less-scary stuff, still with good data and estimates) Force a discussion w stakeholders and developers how to solve. Maybe:? Let em ride, then break down and estimate as the day approaches Insert a “spike” story to inform an earlier breakdown 

@atomicobject http://spin.atomicobject.com 13 Velocity Monday, May 6, 13 A measure of how fast you’re going. How many points the team completes in an iteration/week/sprint. Confidence is built on the fact that our stories are units of value, not just time punched to a clock. Morale for the team, Consistency check. Measure this as you go A number of interesting velocity average calculations available. BUT I forgot to mention my 4th challenge, on top of decomposition, “size” language, and estimation: INITIAL ESTIMATE OF PROJECT DURATION. Still owe that to mgmt. 

@atomicobject http://spin.atomicobject.com 14 Time for Time? Monday, May 6, 13 It is time to talk about time. At least we are no longer suckers. We’ve got a well-defined set of estimated user stories and a firm grasp of overall project scope. Finally, we can answer those annoying business questions: - When will we be done? - How much will it cost? - Are we behind schedule? How far? We can make a plan. We can populate iterations and extrapolate a schedule for completion Since we know exactly how much there is to do, all we have to do is divide velocity into scope and we’ll know how much it’ll cost and the precise date it will be done. Oops... 

@atomicobject http://spin.atomicobject.com 15 Oops! What velocity? Monday, May 6, 13 What velocity? All that hard estimation work is just sitting there idle, without velocity. Recall: - we’ve worked hard to divorce our estimates from time - we’ve given our stories relative magnitudes with arbitrary units - we have no data We should wait to make projections. At least two iterations; 4 or 5 would be better Also nice to build confidence that our stories are reasonably defined and sized. But on many projects, it ain’t right to shrug and say “Dunno” when someone asks “So when do you think we’ll be done?” We need velocity _right now_. We have to guess. 

@atomicobject http://spin.atomicobject.com Yes, you may estimate velocity. 16 Monday, May 6, 13 ...because this guess becomes an _educated_ guess over time. How? Past projects, team sampling of stories “Does this seem reasonable for a week’s work?” I’ve done this a few times to soften early noise in the projections. Lets me show a burnup chart immediately. MAKE SURE CUSTOMERS UNDERSTAND THAT. Gut check and face reality: are we hitting this pace? Will we from now on? (Over time, the data will reveal the accuracy of my guess) 

@atomicobject http://spin.atomicobject.com Now it’s time for “time” 17 time = scope / velocity = total pts / pts-per-iteration Monday, May 6, 13 Once you’ve got scope and velocity, you can calculate duration. Up front, use est. velocity Going forward, your velocity evolves away from a guess and becomes hard data. Being able to talk competently about time on your project opens the door to planning and tracking. 

@atomicobject http://spin.atomicobject.com Agile Planning (abbreviated version) 18 Monday, May 6, 13 Cohn’s book covers the full set of topics, but today I just wanted: Estimation. Agile planning includes things like: Release & iteration planning Velocity tracking Backlog & scope management Burnup charts ...size-based estimation is probably the best foundation for most Agile planning / mgmt practices BUT they are largely orthogonal to the technique of estimation. (I don’t care where the points came from; just let me calculate based on them) 

@atomicobject http://spin.atomicobject.com Iteration Planning 19 Monday, May 6, 13 At Atomic, we drop our stories into a tool that lets us plan and track iterations. Ordering Schedule Status (doing, done, blocked) Generate some basic numbers: - total points, pts per iteration - pts completed, pts remaining 

@atomicobject http://spin.atomicobject.com Burn-up Charts 20 Summary Predicted Finish Predicted Remaining Iterations Budget Total Spent Budget Remaining Percentage through Scope Percentage through Budget Predicted Cost Jul 7, 2011 2 $224,000 $184,450 $39,550 91% 82% $202,953 Web Application Phase 3 0 83 167 250 333 417 500 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Points Iterations Total Points in Project Total Points Completed total points line Monday, May 6, 13 Primary reporting artifact: the burnup. Simple view of what’s happening with scope and velocity Some high-level figures like budget projected completion date. 

@atomicobject http://spin.atomicobject.com (Oh... and... sometimes we do... time estimates.) 21 Monday, May 6, 13 Ok I may have been misleading. There’s another tool we use. By “sometimes” I mean “fairly regularly” for certain projects. AT THE HIGH LEVEL. In the sales process. Need to ballpark the high-level functionality to provide a quote Help customer build a budget Responsible tools! 50/90 range estimates diff-of-squares buffer accumulation Identify areas of risk and uncertainty Still works as a good backdrop for discovery, planning and story breakdown. 

@atomicobject http://spin.atomicobject.com Common Concerns 22 Monday, May 6, 13 Any questions so far? We’ve certainly had our share, from within, from customers etc Let me hit on a few of those 

@atomicobject http://spin.atomicobject.com When is a story “done?” 23 Monday, May 6, 13 Argh. #1: When the customer says it’s done. This is the best possible way to know it’s ok to move on, even though some whistles and bells might be left off. Specifically: Claim points as they’re done (we assume they’ll be accepted) If there’s a problem, the story is re-opened. --> This may result in a velocity hit! There’s always more to do. What you leave on the table now, will come back to you later. Plan for it? Add notes, future stories? Testing -> issues ongoing design -> minor updates Hold on to: the point is to measure and predict progress. 

@atomicobject http://spin.atomicobject.com Do we take points for bugs? 24 Monday, May 6, 13 Should we estimate bugs... ...and put them in the backlog ...and give them priority ...and count bug fixes as velocity? Depends. Try not to. Consistent discovery/repair of defects manifests as a velocity hit. Cleaner, easier to cope with, can discuss clearly with customer. Big-burst test/repair manifests either as scope increase or a strange blank in the schedule (a 0-velocity week or two?). Can be ok if customer understands, - but it messes with velocity calc - and screws up the burnup chart’s visuals 

@atomicobject http://spin.atomicobject.com Will customers accept points as estimates? 25 Monday, May 6, 13 Eventually. Depends on - their experience with Agile. - their experiences with you Very engaged customers will become used to it quickly Will verify for themselves that the numbers correspond to value delivered Enjoy the information they have, and the influence over their project 

@atomicobject http://spin.atomicobject.com What if we estimate wrong? 26 Monday, May 6, 13 Happens plenty. Depends on what you mean by wrong... if it’s early in the game, be patient. If you’ve got a lot of small estimates, it’s ok to be off... it comes out in the wash. If you’re working against a lot of big-ticket items, you should consider getting some smaller- scope items in their place. Decrease the swing. 

@atomicobject http://spin.atomicobject.com What if a customer asks about $/point? 27 Monday, May 6, 13 Give it to them with caveats that it’s an ESTIMATE, and an aggregate. Be wary of what you use the information for. 

@atomicobject http://spin.atomicobject.com Why is this 8-point story still in-progress? 28 Monday, May 6, 13 What happens if a story keeps going and going? Team conversation. Dig into details. What’s the hold up? - external dependency? - more and more work? Possible cause: - Might have identified a task or an infrastructural concept, instead of a story. - Bad estimate. Story is deceptively simple-sounding, but huge and cross-cutting. - Story was scheduled too early and depends on too many other aspects - Story depends on something outside the team or project. New breakdown of stories and estimates surround the story. FOLLOW UP WITH CUSTOMER - this situation often leads to scope increase. 

Thanks! David Crosby [email protected] www.atomicobject.com Monday, May 6, 13