Traditional Planning A Joyless Track Record

Size: px

Start display at page:

Download "Traditional Planning A Joyless Track Record"

Susanna McGee
5 years ago
Views:

to make progress 65% of projects significantly overrun their cost estimates 65% of

1 Agile Project Planning ~ Erik Philippus 1 IMPROVEMENT BV Traditional Planning A Joyless Track Record Much work remains to be done before we can announce our failure to make progress 65% of projects significantly overrun their cost estimates 65% of product features are rarely or never used the average project exceeds its schedule by 100% 2 1

Traditional Planning Causes of Planning Failure Planning is by activity rather than feature - Parkinson's Law Lateness is passed down the schedule - Antipattern: Anti-gravity Module Multitasking

2 Traditional Planning Causes of Planning Failure Planning is by activity rather than feature - Parkinson's Law Lateness is passed down the schedule - Antipattern: Anti-gravity Module Multitasking causes further delays - assigning work to individuals rather than to groups - focus on high level of utilization of all individuals Features are not developed by priority - dropped features may be of greater value than those that are delivered Uncertainty is not acknowledged - product specifications are generally imperfect or incomplete - assignment of precise estimates to imprecise work - estimates become commitments 3 Parkinson's Law Work expands so as to fill the time available for its completion. The Colonial Office had its greatest number of staff at the point when there was a lack of colonies to administer. Colonial Office, London Forces: 1 An official wants to multiply subordinates, not rivals 2 Officials make work for each other 4 2

Organizational Pattern: Anti-gravity Module Risky components are scheduled to be completed last. The launch module is 98% built - all we need is the antigravity module.

3 Organizational Pattern: Anti-gravity Module Risky components are scheduled to be completed last. The launch module is 98% built - all we need is the antigravity module. high risk low low avoid do first do last do second value high 5 Agile Planning Dealing with Uncertainty flexibility to adapt to changing business conditions adaptation plan absolute conformance to original plans anticipation adapt act 6 3

4 Agile Planning Principle #1: Apply Multiple Levels of Planning 2-3 months 2 weeks 1 day portfolio product release sprint day strategic planning focus of agile team 7 Relating the Planning Levels Release 1 Release 2 Release 3 release plan sprint 1 sprint 2 sprint 3-6 task A 4 hours task B 6 hours task C 3 hours task D 8 hours 8 4

5 Relating the Planning Levels product backlog sprint backlog iteration 2 iteration 1 as a., I want to. as a., I want to. as a., I want to. as a., I want to. as a., I want to. as a., I want to. as a., I want to. as a., I want to task A task B task C task D task E task F task G daily scrum 6 hours 4 hours 5 hours 12 hours 2 hours 6 hours 5 hours yesterday, I started to work on. and I should finish before the end of today 9 Conditions of Satisfaction Drivers for Release and Sprint Planning Conditions of satisfaction (user stories, budget, schedule) release Release Planning feedback Conditions of satisfaction (user stories, acceptance tests) sprint Sprint Planning Product Increment 10 5

6 Agile Planning Principle #2: Use a Relative Measure of Size traditional measures of size agile measures of size function points lines of code story points 11 Estimating Size example I'd like 14 ounces of soda, 6 ounces of lasagna, and 3 ounces of bread 12 6

Estimating Size example I'd like a large soda, a medium size lasagna, and a small serving of bread 13 Story Points Story Points are a unit of measure for expressing the overall size of a piece of

7 Estimating Size example I'd like a large soda, a medium size lasagna, and a small serving of bread 13 Story Points Story Points are a unit of measure for expressing the overall size of a piece of work using relative values. Story Points are a measurement of complexity and/or size of a requirement as compared to the duration to complete that requirement. Story Points are used for planning and tracking on release-level 14 7

8 Assignment of Story Points exercise Assign ints' 'Zoo Po g ll fo owin to the : breeds 15 Assignment of Story Points exercise Breed Zoo Points Lion Kangaroo Rhinocerus Bear Giraffe Gorilla Hippopotamus Tiger 16 8

Story Points key advantages Forces the use of relative estimating studies have shown that we're better at relative estimating (over one order of magnitude) rather than absolute

unit-less time-based estimates are not additive 17 Ideal Time Alternative for Story Points Elapsed Time Overall amount of time that passes on a clock or calendar Salvadore Dali ~

9 Story Points key advantages Forces the use of relative estimating studies have shown that we're better at relative estimating (over one order of magnitude) rather than absolute estimating Help to drive cross-functional behavior Focuses us on the size, not the duration derive duration emperically Puts estimates in units we can add together story points are unit-less time-based estimates are not additive 17 Ideal Time Alternative for Story Points Elapsed Time Overall amount of time that passes on a clock or calendar Salvadore Dali ~ Persistance of Time Ideal Time Amount of time something takes when stripped of all peripheral activities It is easier and more accurate to predict the duration of an event in ideal time than in elapsed time 18 9

10 Interruptions meetings demo's phone calls special projects training reviews bug fixing support sick time typically, you are able to work ten minutes between interruptions 19 Estimation in Ideal Days When estimating in ideal days, you assume: 1. The story being estimated is the only thing you'll work on 2. Everything you need will be on hand when you start 3. There will be no interruptions In favor of ideal days: - Ideal days are easier to explain outside the team - Ideal days are necessary/easier to estimate at first However, the preference is for story points! 20 10

21 Team Velocity Velocity is a measure of a team's rate of progress It is calculated

11 Agile Architecting Velocity examples How long will it take to read the latest Harry Potter book? to drive from Amsterdam to Maastricht? 21 Team Velocity Velocity is a measure of a team's rate of progress It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration 22 11

Agile Planning Principle #3: Let Velocity take care of Estimation Errors The correctness of estimates isn't crucial What matters is that they are consistent Velocity corrects most estimation

12 Agile Planning Principle #3: Let Velocity take care of Estimation Errors The correctness of estimates isn't crucial What matters is that they are consistent Velocity corrects most estimation inaccuracies 23 Estimation of Velocity Use historical values Run an iteration Make a forecast Express estimations as a range! iterations low high completed multiplier multiplier 1.6x 1.25x bad time for estimation better time for realistic estimations or more x 0.8x 0.6x The cone of uncertainty 24 12

13 Determining Velocity observed velocity last mean (last eight) mean (worst three) iterations 25 Forecasting Velocity Step 1 Estimate the numbers of hours that each person will be available to work on the project each day - typically 4-6 hours/day for a full-time assignment Step 2 Determine the total number of hours that will be spent on the project during the iteration Step 3 Find a representative set of stories, and expand them into tasks. Estimate each task in ideal hours. Repeat until you have identified enough tasks to fill the iteration. Step 4 Convert the velocity determined in step 3 into a range 26 13

more user stories has changed 27 Agile Planning Principle #4: Estimate Size, but

14 Re-Estimation Do not re-estimate solely because progress is not coming as rapidly as you'd expected golden rule: re-estimate only when the relative size of one or more user stories has changed 27 Agile Planning Principle #4: Estimate Size, but Derive Duration story points ESTIMATION OF OF EFFORT + velocity ESTIMATION OF DURATION 28 14

Agile Estimation in Practice Utilize collaborate estimates Prefer estimations by those who will do the work Use an appropriate estimation scale Remove all (political) bias from the estimate 100

15 Agile Estimation in Practice Utilize collaborate estimates Prefer estimations by those who will do the work Use an appropriate estimation scale Remove all (political) bias from the estimate 100 additional estimation effort yields little value beyond a certain point accuracy 50 effort 29 Use the Right Units can you distinct a 1-point story from a 2? and a 17 from an 18? you need an ever growing scale Use a set of numbers that make sense; I like: 1, 2, 3, 5, 8, 13, 20, 40, 100 (stay mostly in a 1-10 range) include 0 and 1/2 if you want fibonacci sequence 30 15

Planning Poker 1 All the team members have a set of cards 2 Moderator reads description of the backlog item 3 Everyone selects and simultaneously shows cards 4 If estimates vary significantly, high

16 Planning Poker 1 All the team members have a set of cards 2 Moderator reads description of the backlog item 3 Everyone selects and simultaneously shows cards 4 If estimates vary significantly, high and low estimators briefly explain their estimates 5 Repeat steps 3-4 until estimates stop converging 6 Decide estimate for backlog item 7 Move to next backlog item 31 Planning Poker Exercise ID User Stories Estimation (ideal days) As a Software Engineer, I want to have a basic version of the specification, sufficient to assess the potential potential of the application As an Art Worker, I want to have a basic version of the specification, sufficient to develop the artwork for the mockup As a Software Engineer, I want to have specification of the product configuration for the upcoming release As a Product Development Manager, I want to have proof that the application will run without problems in the final product environment???? 32 16

Plannign Poker why it works Combining individual estimates through group discussion leads to better estimates - estimators are required to justify estimates Emphasizes relative rather than absolute

17 Plannign Poker why it works Combining individual estimates through group discussion leads to better estimates - estimators are required to justify estimates Emphasizes relative rather than absolute estimating - focuses most estimates within an approximate one order of magnitude Estimates are constrained to a set of values, so we don't waste time in meaningless arguments Everyone's opinion is heard - those who will do the work, estimate the work! It's quick and fun see for planning poker for distributed teams 33 Prioritizing User Stories Guidelines for prioritizing user stories or themes: The financial value of having the feature The cost of developing / supporting the new feature The amount and signficance of learning and new knowledge created by developing the feature The amount of risk removed by developing the feature The business impact of not having the feature 34 17

18 Relative Penalty Look at features from the perspective of how users will be affected by the presence as well as by the absence of the feature Golden Rule: Incorporate the relative penalty in your prioritization 35 Relative Weighting Feature Relative Benefit Relative Penalty Total Value Value % Estimate Cost % Priority uploading pictures D touchscreen voice recognition Total

19 Desirability of Features Kano Model high Customer Satisfaction unspoken exciters and delighters performance/linear indifferent must-have, mandatory low unspoken absent Feature Presence fully implemented 37 Paired Questions + functional form: If you can upload photo's with your mobile, how do you feel? dysfunctional form: - If you cannot upload photo's with your mobile, how do you feel? I expect it to be that way I am neutral I dislike it that way I expect it to be that way I am neutral I dislike it that way X X 38 19

20 Differentiating Product Features Feature Implemented user perception Don't Like Neutral Expect Feature Absent Don't Like Neutral Expect skeptical reverse reverse must-be linear indifferent delighter reverse skeptical 39 Tracking release burn-down chart 250 story points point project completed in 8 sprints sprint 40 20

21 Tracking release burn-down chart story points Burn down charts: Raise questions, they 240-point project don't answer them completed in 8 iterations Facilitate early discussions Make it impossible to lie sprint 41 Tracking Release Burn-down Bar 300 work is completed work is re-estimated story points 0-50 new work is added work is removed sprints 42 21

22 Multiple-team Projects Planning a complex projects with many interteam dependencies may require: establishing a common basis for estimates - story points or ideal time adding detail to the user stories sooner - allows multiple teams to coordinate work performing lookahead planning - maintaining a rolling lookahead window during release and iteration planning incoporating feeding buffers into the plan - preventing late start of a team caused by a late delivery of another team 43 Release Planning 5-10 iteratons 2-5 months combination of schedule, scope resources do in any sequence Select sprint length Determine conditions of satisfaction Estimate the user stories Estimate velocity Select stories and a release date estimation in story points iterate until the conditions of satisfaction for the release can best be met Prioritize user stories 44 22

23 Sprint Planning do in any sequence Adjust Priorities Identify sprint goal 1 sprint 2-4 weeks Select user stories Determine target velocity ask team for commitment Split user stories into tasks equals most recent velocity (for new teams, forecast velocity) Estimate Tasks estimation in ideal hours 45 start of upcoming sprint Strategic Planning product backlog 1 quarter ahead product backlog with prioritized user story estimations updated launch plan with rough estimations quarter 46 23

24 Agile Architecting Agile Project Planning 8 reasons why it works Estimates of size and duration are separated - translate story points into duration using velocity Plans are made at different levels - 3 different levels/perspectives: release, sprint, daily Plans are based on features, not tasks - focus on product that must be built Small stories keep work flowing - short cycle times will deliver value as fast as possible Work in progress is eliminated every sprint - no high amounts of work in progress, 'Kanban' principle Tracking is at the team level - buidling commitment; elimination of the 'blame game' Uncertainty is acknowledged and planned for - express uncertainty in either the functionality or the date 47 Agile Architecting Essentials - Agile Estimation & Planning References Agile Architecting 1 Mike Cohn Agile Estimating and Planning, Prentice Hall, Todd Little: Software Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty, IEEE Software, May 2006, Vol. 23, No. 3 3 Kent Beck and Martin Fowler Planning Extreme Programming, Addison-Wesley, George D. Githens Rolling Wave Project Planning, Agile Architecting Essentials - Agile Estimation & Planning 48 24

Owning An Agile Project: PO Training Day 2

Owning An Agile Project: PO Training Day 2 Petri Heiramo Agile Coach, CST Product Management PO Product management is a larger scope than what Scrum defines as a PO Or rather, Scrum implicitly assumes