Agile Estimation and Planning. Martine Devos

Transcription

1 Agile Estimation and Planning Martine Devos copyright Martine Devos 2007

2 SPIN São Paulo meeting Brazil Date: August, (Monday) Time: from 6:30 to 9:00 PM Place: Fundacao Carlos Alberto Vanzolini Paulista Avenue, floor - Sao Paulo - Brazil

3 Estimation and Planning Focus on Agile Beyond Agile 8/7/2007 copyright Martine Devos 3

4 Estimation has a bad reputation Estimation is the most optimistic prediction that has a non-zero probability of coming true what is the earliest date by which you cannot prove you will not be finished - estimating Tom DeMarco (cited by Mc Connell) 8/7/2007 copyright Martine Devos 5

5 Urban legends Complicated formulas are more accurate than simple estimates We need to correct estimates with factors for team collocation, experience reality is opposite the more chances for subjectivity to creep They will not let us management does not want correct estimates, they just want a date Many so called estimation problems arise from misunderstanding what an estimate is and blurring other similar-but-not-identical concepts with estimation. 8/7/2007 copyright Martine Devos 6

6 What is an estimate? 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project 3. A judgment based upon one s impressions; opinion (source: American Heritage Dictionary, Second College Edition, 1985) Does this sound like what we are asked for (asking for) an estimate? When executives ask for an estimate, they re often asking for a commitment or for a plan to meet a target. 8/7/2007 copyright Martine Devos 7

7 Glossary A Target = a statement of desirable (often much needed) business objective A Commitment = a promise to deliver defined functionality at a specific level of quality by a certain date. Commitment can be the same as an estimate, it can be more aggressive or more conservative. It does NOT have to be the same as the estimate. An Estimate should be treated as an unbiased, analytical process the goal is accuracy, not to seek a specific result Planning should be treated as a biased, goal-seeking process the goal is to seek a particular result Combining estimation and planning ends up in a poor estimate and a poor plan or both We refine estimates over time and we improve the plan 8/7/2007 copyright Martine Dweevos 8

8 A typical conversation Executive: How long do you think this project will take? We need to have this ready in 3 months for a trade show. I cannot give you any more team members, so you will have to work it out with your current staff. Here is the list of features we will need. Later, the project lead: We have estimated it will take 5 months. Executive: Five months? Did not you hear me? I said we needed it ready in 3 months for the tradeshow. 8/7/2007 copyright Martine Devos 9

9 A better conversation Executive: How long do you think this project will take? We need to have. Project lead: Let me make sure I understand what you are asking for. Is it more important for us to deliver 100% of the feature, or is it more important to have something ready for the tradeshow? Executive: We have to have something ready for the tradeshow. We would like 100% of those features if possible. Project lead: I want to make sure I follow through on your priorities as best as I can. If it turns out that we cannot deliver 100% of the features by the tradeshow, should we be ready to ship what we have or should we plan to slip the date beyond the tradeshow? Executive: We have to have something for the tradeshow, so we have to ship something even if it is not 100% what we want. Project lead: OK, we will come up with a plan for delivering as many features as we can in the next 3 months. 8/7/

10 What if there is Mismatch between goal and estimates? Tell a lie to keep our job? Negotiate the estimate? If the mismatch is allowed to persist the options will be far fewer There are NO white lies. NO! The detection of a mismatch between the project goal and the project estimate should be interpreted as useful, early-in-the-project risk information. And allow the projectteam to make the right decisions 11

11 AGILE PLANNING 8/7/2007 copyright Martine Devos 13

12 Planning and Project Parameters Keeping the project in equilibrium Time, cost, and resource availability bound scope and quality TPM Project plan identifies time, cost and resource availability to deliver scope and quality creep See: Wysocki, McGary 14 8/7/2007 copyright Martine Devos 2007

13 Project Management Variables Velocity turning Product Backlog into increments of functionality Product Backlog Time Other variables: Quality, Value 8/7/2007 copyright Martine Devos

14 Learning from the Burndown Start date Current date Target date Actual stories Planned 8/7/ copyri ght Martin e Devos

15 Making a plan We need units We need measure of capacity and progress Units: Story Points :ITD (Ideal Team Day), IPD (Ideal Person Day) Measure of Progress: Velocity Easier to know after the facts yesterday s weather 8/7/2007 copyright Martine Devos

16 Reducing Encertainty Why do we plan? Why do we estimate? high low high low high high What? What? low How? Waterfall Approach low How? Agile Approach

17 Agile and Traditional Breakdown Structures Traditional focus on input Work Breakdown Structure -- WBS Agile focus on output Focus on outputs Feature Breakdown Structure -- FBS Feature Sets Architecture Component Breakdown Structure -- CBS 8/7/2007 copyright Martine Devos

18 Value Creation in Agile Methods Value Time copyright Martine Devos 2007

19 Core to agile success is feedback Reduce the Black-Out Periods Done is Binary - done/not done 8/7/2007 copyright Martine Devos 24

20 Important: What does it mean to be done? We report Done or Not Done binary No 90 percent done or Almost there 8/7/2007 copyright Martine Devos

21 Focus of Agile Planning Levels of Planning Strategy Portfolio Product Release Sprint Day multilevel Agile focus is on planning between product (considered +/- defined) and iteration. Daily planning is team s concern Mike Cohn calls it the Planning Onion

22 Cone of uncertainty Vision estimate -75% % Exploratory estimate -50% % Budget estimate -20% % Commitment estimate -10% -+ 10% 8/7/2007 copyright Martine Devos 27

23 Correspondence with 3 Levels of Precision in agile Stories in story points Tasks in hours (estimate) Looking back at daily scrum: I worked for X hours on the UI and I will be able to finish before the end of the day (actual time) Car rental system As a user, I want to As a renter, I want to Write test fixture Code UI Release 8/7/2007 copyright Martine Devos 28

24 Writing Product Backlog Items The items in the product backlog are described a various levels of detail and granularity: Newspaper style copyright Martine Devos 2007

25 Stories Refine the Project Backlog Backlog items come in many shapes and sizes Transform backlog to actionable stories Stories are small, and only come in a few sizes

26 In an iteration: from story to task Story a 5 Story b 6 Story c 4 Story d 3 Story e 5 Story f 5 Story g 3 Story h 3 Story i 5 Story j 5 Story k 3 Story l 8 Story m 2 Code UI 12 Code 5 database Script tests

27 Cone does not improve itself Estimates improve When we collect data Reflect on estimates Remove variability Making decisions Keeping team stable NOT by spending more time estimating Strong stimulus for Product Owner and Managers to make decisions 8/7/2007 copyright Martine Devos 32

28 ESTIMATION 8/7/2007 copyright Martine Devos 33

29 Accuracy and (Unwarranted) Precision Shortest possible schedules are achieved by creating the most accurate possible not the most precise estimates If you want to achieve maximum development speed avoid false precision An estimate of days may be accurate but not precise An estimate of 35 days for the same situation creates a false feeling of precision days + or 2 months 3741 hours for a feature Estimates in hours at Release planning (NOT enough detail available!) = unwarranted precision Is Pi = better than Pi is 3? 8/7/2007 copyright Martine Devos 34

30 StoryPoints Floorplan You are hired to paint this house, materials will be there You only have the floorplan, did not see the actual house. You estimate the two bedrooms to be each 5 points How long will it take to paint this house. 37

31 Tool: Planning Poker Group technique Precision decreases as story size increases, therefore constrain estimates to pre-defined values (e.g. 1, 2, 3, 5, 8, 13 and 21 (or big) 8/7/2007 copyright Martine Devos 38

32 Wideband Delphi Estimation Iterative approach for improved estimates Every developer gives his estimate Discuss differences, especially extremes Re-estimate until convergence 8/7/2007 copyright Martine Devos 39

33 Planning tools? Story-cards Wall, white board Later used to show to and track progress at all time 8/7/2007 copyright Martine Devos 40

34 PRESENTING ESTIMATES TO OTHER STAKEHOLDERS

35 Start with a range indicating the uncertainty Rather than losing the customer s confidence by taking one schedule slip after another, you build confidence by meeting the expectations and by tightening the ranges = REFINING ESTOMATES estimate Initial concept 3-24 Approved product definition Requirements complete User interface design First interim release

36 Quantify risk in estimates Estimate 10 features 6 months (+3-2) +1 for late delivery of graphics formatting system + 1 for new dev tools not working as well as expected for staff sickness +0.5 for underestimating by new members - 1 for less delay in hiring new developer - 1 for new dev tools working better than expected 8/7/2007 copyright Martine Devos 44

37 THERE'S NO POINT IN BEING EXACT ABOUT SOMETHING IF YOU DON'T EVEN KNOW WHAT YOU'RE TALKING ABOUT. JOHN VON NEUMANN copyright Martine Devos 2007

38 Killer: We already have all the requirements Relating stories to requirements and legacy backlog CARD Conversation STORY TEST Market assessment Customer profiles User wanted behavior User stories Technical realization requirement specs requirement 1 F1.1 F1.2 requirement 2 F2.1 F2.2 8/7/2007 copyright Martine Devos 46 F2.2. 1

39 The Planning Bucket Once the bucket is full, the planning stops Maintenance,. Be aware that skills and knowledge distribution within the team can also constrain the team s capacity Gross hours The Planning Bucket Net hours Overhead

40 copyright Martine Devos

41 Martine Devos Skype: mmdevos mmdevos@acm.org 8/7/2007 copyright Martine Devos

42 References Excellent book: Steve Mc Connell, Software Estimating Intro to agile estimation and planning: Mike Cohn, Agile Estimation and Planning 8/7/2007 copyright Martine Devos 52