Innovative Techniques for Agile Estimating & Planning

Transcription

1 Agile Management Seminar Series Bringing you the experts in agile management and agile development methods. World-renowned faculty includes: Kevin Aguanno, agile project management guru and author; Scott Ambler, creator of Agile Modeling, Agile Data, and the Agile Unified Process; Mark Kozak- Holland, author of Winston Churchill, the Agile Project Manager; and more... Innovative Techniques for Agile Estimating & Planning ½ Day Workshop Multi-Media Publications Inc. All rights reserved. Box 58043, Rosslynn RPO, Oshawa, ON, Canada, L1J 8L6. Phone: (905) / Fax: (905) Web: / orders@mmpubs.com

2 Kevin Aguanno With over 17 years of managing complex systems integration and software development projects, Kevin Aguanno is known in the industry for his innovative approaches to solving common project management problems. He focuses on two project management specialty areas: agile project management and troubled project recovery. As a well-known keynote speaker, trainer, and coach in agile management methods, Aguanno has taught thousands of people how to better manage high-change projects by using techniques from Scrum, Extreme Programming, Feature-Driven Development, and other agile methods. He is a frequent presenter at conferences and private corporate events where he delights audiences with practical advice peppered with fascinating stories from his own experiences in the trenches practicing agile project management. He has taught for several years at the University of Toronto where he won the coveted Excellence in Teaching Award, and is a regular guest lecturer in software engineering and project management classes at several other universities. Credentials Kevin Aguanno holds a B.A. from the University of Western Ontario, and a Master s in Project Management from the School of Business and Public Management at George Washington University. He is a PMI-certified Project Management Professional (PMP), and his competency is certified by IBM as a Certified Executive Project Manager and by the International Project Management Association (IPMA) as a Senior Project Manager (IPMA Level B). Aguanno is an active member of the Project Management Institute (U.S.A.) including the Information Systems SIG, the American Society for the Advancement of Project Management (U.S.A.), the Association for Project Management (U.K.), and the Project Management Association of Canada where he is a founding director. He is accredited by the International Project Management Association (Geneva, Switzerland) as a project management competency assessor, and he performs IPMA Level-B and IPMA Level-C assessments for the ASAPM in the U.S.A. Publications Kevin Aguanno is the author of over one dozen books and audiobooks including: Managing Agile Projects An Introduction to Agile Stealth Methodology Adoption Agile Project Management Using Scrum Managing in the Face of Ever-Changing Requirements Agile Adoption Made Easy Extreme Scrum So, You Think You re Done? 101 Ways to Reward Team Members for $20 (or Less!) S-T-R-E-T-C-H Your Rewards Budget: Maximize the Return on your Employee Recognition Investment Beyond the PMP: Advanced Project Management Certification Options - unpublished Insider Tips for Agile Test Management - forthcoming

3 Innovative Techniques for Agile Estimating and Planning Providing Predictability in the Face of High Levels of Change and Complexity V4.3 (27 April 2011) Your Presenter: Kevin Aguanno 20+ years of PM experience 20+ published books, audiobooks, DVDs, and CD-ROMs most on agile and PM-related topics IBM Certified Executive PM IPMA Certified Senior PM (IPMA B) IBM AIS Agile Centre of Competency Lead IPMA-Accredited PM Competency Assessor for Canada and USA (C) 2011 Kevin Aguanno. 1

4 Agile Estimating and Planning Introduction & Review Course Outline Agile Overview Why Plan and What Makes a Good Plan? Why Traditional Planning Fails Agile Planning Estimating with Story Points {15-minute break} Estimating with Ideal Days 3-Step Feature Prioritization Process Measuring and Forecasting Velocity Critical Chain Estimating and Scheduling Why Agile Planning Works Wrap Up & Evaluations An Overview of Agile (C) 2011 Kevin Aguanno. 2

5 Agile Manifesto Adherents stress: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more The Agile Alliance Agile Development Principles Project Characteristics: Early and continuous delivery of usable deliverables Usable deliverables measure progress Accept changing requirements, even late in project Short delivery cycles Simplicity in all aspects Sound, flexible design/architecture is essential (C) 2011 Kevin Aguanno. 3

6 Iterative and Incremental Delivery Month 1 Month 2 Month 3 Waterfall A/B/C Iterative A B C A B C A B C Incremental A A+B A+B+C Agile A 1 B 1 C 1 A 1,2 B 1,2 C 1,2 A 1,2,3 B 1,2,3 C 1,2,3 The Agile Approach is Iterative AND Incremental Predictability Varies as should Metrics Deterministic (Plan-Based) Empirical (Observation- Based) Waterfall Incremental Iterative Agile Focus is on adherence to plan Focus is on delivering value to customer (C) 2011 Kevin Aguanno. 4

7 To Recap Agile methods are built upon the engine of iterative and incremental delivery Benefits: Improved responsiveness to change More customer input/control/feedback allowed Less risk (building the wrong thing, building the right thing wrong) Visible/verifiable progress How Scrum Manages Requirements Changes SCRUM Structure Initial List of Features Grouped List of Features Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Feature 7 Planning Feature 1 Feature 3 Feature 7 Feature 2 Feature 4 Feature 5 Sprint #1 Sprint #2 Integrated Demonstration Closure Feature 6 Product Backlog By Kevin Aguanno. (C) 2002 Element K Journals. (C) 2011 Kevin Aguanno. 5

8 Progress Metrics XP: Velocity (Features Completed / Planned) Scrum: Sprint Burndown Chart (Est. Hours Remaining vs. Date) FDD: Cumulative Features Completed (# Features vs. Week) Quality Management Common quality management techniques suggested by agile methods include Early and continuous testing (more time to fix defects, less cost for remedial activities) Test-Driven Development (focus on objective quality criteria) 100% functional testing each build (or at least each iteration) Code/Design inspections/pair programming (C) 2011 Kevin Aguanno. 6

9 Deliverables Acceptance Using agile methods, final sign-off/acceptance of deliverables is usually trouble-free, due to Test-Driven Development (start with useracceptance tests) Customer involvement in (re)prioritization Short iterations with demonstrations at iteration end (frequent customer feedback) These elements of agile methods make sign-off easier when dealing with multiple sponsors. Agile Methods are Harder to Implement in Some Situations Large teams Complex team organizational structures Geographically-scattered teams Life- or mission-critical applications (C) 2011 Kevin Aguanno. 7

10 Why Plan and What Makes a Good Plan? Planning is everything. Plans are nothing. Field Marshal Helmuth Graf von Moltke ( ) Why Plan? Planning is a quest for value, an attempt to find the optimal solution to what should be built and how to build it. (C) 2011 Kevin Aguanno. 8

11 Planning improves the chances of success by: Reducing Risk Thinking through the possibilities allows us to take preventative actions Improving Understanding Helps prevent building the wrong thing Supporting Decision Making Data provides a basis for understanding trade offs, etc. Conveying Information Conveys expectations Describes one possibility of future project events Establishing Trust Creating reliable estimates 2011 Kevin Aguanno. All & rights plans reserved. What makes a good plan? Stakeholders should find it good enough to use as a basis for decision making (C) 2011 Kevin Aguanno. 9

12 Why Traditional Planning Fails No plan survives contact with the enemy. Field Marshal Helmuth Graf von Moltke ( ) The Cost of Traditional Planning Feature Usage Within Deployed Applications Often 13% Always 7% Never 45% Sometimes 16% Rarely 19% Source: Chaos Report v3 (C) 2011 Kevin Aguanno. 10

13 We traditionally plan by task, not by feature Traditional methods focus on the completion of tasks rather than delivering features. Customers get little value from the completion of tasks. Features are the true measure of customer value. When we review traditional task-based schedules, we tend to look for forgotten tasks rather than for missing features. With little effort at feature prioritization across multiple releases, we tend to build all features in one release, regardless of importance/value to the business. Tasks rarely finish early Parkinson s Law: Work expands to fill the time available for its completion. People s natural tendency is to not work as fast when there is lots of time available for a task. An official schedule showing a week to complete a task gives implicit permission to take that full week. If done early, people may gold plate the solution by adding extra features not requested by the sponsor. People also spend more time researching novel approaches to the solution if they perceive that they have lots of time. There may be a fear that if people finish early, they may be accused of padding their estimates or that they will be expected to complete their other work early too. (C) 2011 Kevin Aguanno. 11

14 Delays cascade through the project schedule Traditional task-based plans focus on dependencies between tasks. Late completion of one task can cause following tasks to also be late. This is exacerbated by the earlier point that tasks rarely finish early. As a result, in traditionally-planned projects, testing rarely gets to start early and early completion is rare. Multi-tasking causes further delays Multi-tasking hurts productivity. With two tasks, productivity improves as a person can switch to one while the other is blocked by something. We rarely only have two tasks, however, and productivity rapidly drops off after two tasks are assigned concurrently. Apart from time lost when switching between tasks (or projects), a person loses focus/concentration. % Time Working on Tasks Effects of Multi-Tasking on Productivity # Concurrent Tasks Source: K. Clark and S. Wheelwright. Managing New Product and Process Development: Text and Cases. The Free Press, (C) 2011 Kevin Aguanno. 12

15 Multi-tasking causes further delays (cont d) Multi-tasking becomes a significant issue once some tasks finish late. It is usually encouraged to increase overall team member utilization, rather than maintaining sufficient slack to cope with typical project variability. Loading the team to 100% capacity is like loading a highway to 100% capacity no one makes any progress. Features are not developed by priority In traditional plans: Work is prioritized and sequenced for the convenience of the development team. All requirements/work must be completed, so the sponsor should not care about the sequence. Near the end of the project, the team scrambles to meet the schedule by dropping features, but with no effort to prioritize features up front, critical features could get dropped. (C) 2011 Kevin Aguanno. 13

16 We tend to ignore uncertainty We assume that the requirements analysis led to a complete and perfect specification. We assume that sponsors will not change their minds, refine their opinions, or come up with new needs during the project. We ignore uncertainty about how we will build the product. We assign precise estimates to this uncertain work. Estimates become commitments The only way we will know the project costs for sure is to look at the actuals when the project is over. Humans cannot see the future, so we estimate based on our experience and the information at hand including its inherent uncertainties. Each estimate has a confidence level (probability) associated with it. In traditional projects, these estimates get seen as commitments, even when they are at less than 100% probability. (C) 2011 Kevin Aguanno. 14

17 Reduction in Uncertainty Estimate Variance Initial Product D efinition Approved Product D efinition Requirements Specification Product Design Specification Detailed Design Specification Accepted Solution Agile Planning A good plan [ ] executed now is better than a perfect plan executed next week. General George S. Patton Jr. ( ) (C) 2011 Kevin Aguanno. 15

18 Agile approach to projects Plan on a multi-disciplinary team. Include sponsor/product owner, project manager, developers, designers, and testers/qa. Break project into short iterations. Timebox each iteration. Typically, 2-4 weeks. Deliver something each iteration. Iterations deliver products that are of releasable quality. Focus on business priorities. Deliver features (not tasks) using user stories, prioritized by the business. Inspect and adapt. Update the plan to reflect actual experiences and the benefits of new knowledge. Adjust priorities at the start of each iteration to maximize the ROI. Agile teams have three levels of planning Release Plans To prepare project-level schedule, resource plans, and overall scope. Iteration Plans To identify high-priority features to be completed in the next iteration. To plan the work (tasks) required to build the selected features. Day Plans Informal discussion during the daily meeting/call to coordinate work and share information. Planning the activities leading up to the completion of a task. (C) 2011 Kevin Aguanno. 16

19 What is Release Planning? Building a high-level project schedule identifying: # Iterations & their start/end dates Releases & their start/end dates Key business milestones Interlocks with other projects Initial contents for each iteration (stories/features, not tasks) Release Planning Constraints - Budget - Schedule Requirements - User Stories - Features Estimate Size Prioritization and Grouping 1) Business Priority 2) Technical Dependencies 3) Logical Groupings Divide into Iterations 1) Choose Iteration Length 2) Estimate Velocity 3) Divide Into Iterations 4) Prepare High-Level Schedule (C) 2011 Kevin Aguanno. 17

20 3-Step Feature Prioritization Process "Strategy is a style of thinking, a conscious and deliberate process, an intensive implementation system, the science of insuring future success." Dr. Pete Johnson (a.k.a. Dr. Strategy ) After estimating story size, prioritize the list 1. Calculate the business priority Factors: a) Financial value (NPV, IRR, payback, etc.) or customer service value b) Cost of developing/supporting (can divide actual costs for last iteration by # story points for an avg. $/point to use in foreward planning) c) Amount of learning (about product and process) and personal skill development (tools, etc.) d) Amount of risk removed e) Legal/Compliance requirements 2. Factor in technical dependencies 3. Adjust for logical groupings (C) 2011 Kevin Aguanno. 18

21 Risk can be an important deciding factor Avoid Do First Risk Do Last Do Second Value Project Backlog Contents: Example Identify Backlog Items (C) 2011 Kevin Aguanno. 19

22 Project Backlog Prioritization 1. Calculate the business priority Factors: a) Financial value (NPV, IRR, payback, etc.) or customer service value b) Cost of developing/supporting (can divide actual costs for last iteration by # story points for an avg. $/point to use in foreward planning) c) Amount of learning (about product and process) and personal skill development (tools, etc.) d) Amount of risk removed e) Legal/Compliance requirements Project Backlog Prioritization: Example Assign Business Value (C) 2011 Kevin Aguanno. 20

23 Project Backlog Prioritization: Example Sort by Business Value Project Backlog Prioritization: Example Factor in Logical Dependencies (C) 2011 Kevin Aguanno. 21

24 Project Backlog Prioritization: Example Estimate Complexity (Points) Estimating for Release Plans When at the Estimating Size step of the release planning process, you can use one of two methods: Story Points A unit of measure for expressing overall size, complexity, risk, etc. of a user story/feature. An abstract unit, not directly convertible to hours, days, etc. Based on completion of the story/feature by the whole team. Ideal Days A day of development work with full utilization (no multitasking, no interruptions, no technical difficulties). Needs to be added up for all people involved in defining and completing the story. (C) 2011 Kevin Aguanno. 22

25 Estimating With Story Points It is better to be roughly right than precisely wrong. John Maynard Keynes ( ) Estimating with Story Points Use one of two techniques to get started: Find the smallest user story and assign it a value of 1. Or, find a medium-sized story and assign it a value of 5. Then, as a group, assign all remaining stories a value between 1 and 10 based upon their relative complexity and risk to the other stories. E.g. a story that is a 4 should be twice as complex as a story that is a 2. Don t over-analyze. Ask a few questions of the product owner, make some assumptions, take a guess, and move on to the next story. (C) 2011 Kevin Aguanno. 23

26 Estimating with Story Points (cont d) Use a 0-10 point scale (zero for simple freebies ) You can spend too much time trying to distinguish between a 6 and a 7, for example, so try to use: 0 for simple, free no-cost or low-cost stories. (Explain that by putting too many of these in a single iteration, they will start to add up into points. 13x0 > 0.) 1, 2, and 3 for low-complexity stories. Studies show that we are good at distinguishing between simpler levels of complexity. 5 for medium complexity. 8 for high complexity. 10 for very high complexity. You can use 20, 40, and 100 for estimating epics and themes. Epics are large user stories you have not bothered to break down yet. Themes are groupings of related stories that can be treated as one unit for planning purposes. E.g. reports. The Agile Planning Game (C) 2011 Kevin Aguanno. 24

27 Avoiding the dangers of group estimating There is a human tendency towards group think If you go around a room asking estimates to gain a consensus, some with deviating opinions will not speak up due to inadvertent group pressure To fix this, everyone needs to present their estimates simultaneously. An example Initial Simultaneous Estimate User Story John Mary Paul As a site visitor, I want to be able to subscribe to the company newsletter Simultaneous Re-estimating after a Brief Discussion User Story John Mary Paul As a site visitor, I want to be able to subscribe to the company newsletter (C) 2011 Kevin Aguanno. 25

28 Handle simultaneous estimating using planning poker cards Each estimator has a set of cards Special-purpose cards Fibonacci series cards - printed out and laminated (1,2,3,5,8,13,21,34) Regular playing cards (Ace = 1 point; 2-10 = face value, J/Q/K = 20/50/100 points, and ace=infinity) Basic Planning Poker TM process Facilitator reads out the user story + notes Team may ask product owner questions (high level) When questions answered, or timebox is out, everyone selects the card with the # points and puts it facedown on the table. (C) 2011 Kevin Aguanno. 26

29 Dealing with discrepancies On the facilitator s cue, everyone turns over their card If there was a big range, team discusses high and low estimates; perhaps, because someone thought of something others forgot about. Everyone puts their card back in the deck and rethinks the story. The team then comes back to the table to try again for a consensus on the second round. The process is repeated, over and over until a consensus is reached, or all remote concerns have been dealt with outside of this project. Process ends when consensus is reached, or when the difference is minimal and explainable. Please note that timeboxing is a good way to constrain the time for these activities. Finally, apply adjustment factors to the estimates A best practice is to add adjustment factors to the estimates after the planning poker rounds have completed. These fudge factors are added in to: Discourage poorly conceived options Adjust for fuzzy requirements or lack of stakeholder buy-in for the project Adjust for resource availability issues Adjust for large teams Add time for dysfunctional work environments Adjust for technical or business risk Etc. Don t get too granular or heavy-handed with these adjustment factors. (C) 2011 Kevin Aguanno. 27

30 Estimating With Ideal Days Ideals are like stars: you will not succeed in touching them with your hands, but like the seafaring man on the ocean desert of waters, you choose them as your guides, and following them, you reach your destiny. Carl Schurz ( ) Estimating with Ideal Days Ideal time differs from elapsed time because of the natural overhead and distractions we experience: Supporting the current release Sick time Meetings Demonstrations HR activities Phone calls Training Reviews / walk-throughs Task switching when multi-tasking (C) 2011 Kevin Aguanno. 28

31 Estimating with Ideal Days (cont d) Problems arise when estimates are given in days with no qualification as to what a day means. Using the term Ideal Days helps to relieve this situation. Ideal Days is a measure of size, not duration. Assign one estimate to a story that is the sum of the Ideal Days estimates for each role required to complete the story (management, analysis, design, development, and testing). Story Points vs. Ideal Days Story Points Help drive cross-functional behaviour Estimates do not decay as skills develop, etc. A pure measure of size Faster than estimating Ideal Days Ideal Days More in-depth analysis of the tasks required to build a story. Easier to explain to outsiders, though there is a risk of having Ideal Days compared to calendar days Easier than Story Points to estimate at first My Ideal Days are not your Ideal Days (skill levels affect Ideal Days estimates) Chance of missing input from a key role (C) 2011 Kevin Aguanno. 29

32 Measuring & Forecasting Velocity The order in which you do something determines the velocity with which you can act, or, the velocity with which you act determines the order in which you can do something. Tim O Connor Velocity A measure of the team s rate of progress. Calculated by summing up the number of story points or ideal days that the team completed in its most recent iteration. For example, if a team completed ten story points last iteration, assume they can do ten again this iteration. Agile methods estimate size, not duration. Duration is derived from the size. Story points or ideal days are turned into a schedule by applying velocity. Add up all of the story point or ideal days totals for the project. Get the team s velocity for a specific iteration length. Divide the point or day total by the velocity to determine the number of required iterations. This forms the basis for the release plan. (C) 2011 Kevin Aguanno. 30

33 Velocity (cont d) The beauty of using velocity as a measure for planning, is that it doesn t matter if our estimates are correct, just that they are consistent. With consistent estimates, measuring velocity over the first few iterations will allow us to prepare a more reliable schedule. To estimate velocity new projects, you can use: historical values (if team, tools, technology, etc. are the same) run an iteration to get actuals (or 3 iterations and take avg. or range) Or, make a forecast Estimating Initial Velocity: Using Historical Values For iteration 1, use the actual velocity from a past project only if: Same team Same technology/solution (e.g. developing version 6.1 based on existing version 6.0) Similar types of scope/backlog items For iterations 2 to n inside a project, use the last iteration s velocity (C) 2011 Kevin Aguanno. 31

34 Estimating Initial Velocity (Simple): Forecasting Velocity for Fixed Team NOT the best approach, but one that we need in our toolkit. Steps: 1. Estimate the # hours/day available to work on the project for each team member. (Typically, 60%-70% productivity for dedicated resources.) 2. Select the number of team members to be used only those producing deliverables, not managers, etc. 3. Select an iteration length 4. Determine the total # hours spent on the project during an iteration. (= # hrs/day x # people on team x # days in iteration) 5. Pick a few random stories and expand them into tasks and estimate the # effort hours per task, getting a total # hours for each story. 6. Gather enough stories so that the # hours for each story adds up to the # hours available in an iteration. 7. Count up the story points for the selected stories to determine projected velocity. Weakness: Assumes all team members included in calculation are equally productive and that they are all equally producing deliverables does not identify overburdened resources Estimating Initial Velocity (Advanced): Forecasting Velocity for Optimal Team This method is more accurate than the simple method. Steps: 1. Select a sampling of user stories of varying size and importance (usually 5-8 is enough). 2. Do an old-fashioned, detailed, bottom-up estimate in hours per resource type to design/build each story. 3. Select an iteration length 4. Determine how many stories will fill up the hours available in an iteration for the most utilized resource (i.e. most # hours of work for each story usually the developers) 5. Now keep adding developers to increase the number of stories that can fit in the iteration until you optimize the less-utilized resources; or, stop when you hit the # developers available to the team. 6. Add up the story points assigned to all the stories that can fit into the iteration with the chosen team size this number is your initial forecast velocity. (C) 2011 Kevin Aguanno. 32

35 Building the Initial Release Plan: Carving Up the Project Backlog Using the forecast velocity, carve up the project backlog into chunks of the appropriate size (+/- a point or two will likely be OK) If a chunk is much smaller than the velocity forecast, but the next piece would push it way over, then look down the list for the next piece that would fit and move it up the list into the current chunk Each chunk represents the scope for one iteration For our ongoing example, let s assume an initial forecast velocity of 10 points. Building the Initial Release Plan: Example Carving Up the Project Backlog (C) 2011 Kevin Aguanno. 33

36 Building the Initial Release Plan: Plotting Iterations on a Calendar View Plot the iterations on a calendar view with real project start dates to get a realistic view. On high-uncertainty/high-risk projects where the end date will not move, it is good practice to leave one or two iterations before the end of the project to absorb: Scope increases The risk of technology challenges and defect correction work affecting velocity The risk of poor team performance Building the Initial Release Plan: Example Plotting on a Calendar View Note: In this example, we dropped the original scope for Iteration 9 (Additional Resources, Bibliography, Dedication) as it was not possible to achieve this by our Feb. 15 deadline while still having some contingency/buffer to protect our unmovable project end date. (C) 2011 Kevin Aguanno. 34

37 Identifying Constraint Dates Mark on the calendar: Interlocks/dependencies with other projects Using another s deliverable Providing deliverables to another Key business milestones/constraint dates/periods Major presentations (e.g. architecture review board meetings, trade show demos, board of directors presentations, etc.) Business events affecting the project (e.g. system change blackouts, office closures, etc.) Holidays/vacation periods (e.g. Christmas week, Canada Day/Independence Day week, etc.) that affect productivity Building the Initial Release Plan: Example Identify Constraint Dates (C) 2011 Kevin Aguanno. 35

38 Defining Releases Release: A wave of solution development ending in a deployment/use of the solution by the business, consisting of one or more iterations. Most projects have 1-3 releases, though some release every iteration. A release should have enough critical mass for the business to bother going through the costs of acceptance testing and deployment. Building the Initial Release Plan: Example Defining Releases (C) 2011 Kevin Aguanno. 36

39 Adjusting Release Plan Now move stories/features from iteration to iteration to reflect: Dependencies Key business milestones/constraint dates/periods (demos, blackouts, etc.) Lower productivity periods due to planned holidays Resource leveling Required release functionality Building the Initial Release Plan: Example Adjusted Release Plan By reducing the # points achievable in the Christmas period, scope items (features) flow out to the right, cascading through the remainder of the schedule. We had to drop feature 17 (Index) to leave a buffer in Iteration 9. We could now include features 18, 15, and 2 (Additional Resources, Bibliography, Dedication) to fill in unused capacity in Iteration 8. Release 1, to be used for early endorsements, would not include 3 chapters that will appear in the final release. (C) 2011 Kevin Aguanno. 37

40 Iteration Planning Inputs - Actual Velocity - Reprioritized Release Plan Requirements Analysis Gather Acceptance Criteria Plan by Task Verify Resource Requirements 1) Identify Tasks (WBS) 2) Estimate by Hours of Effort 3) Prepare Schedules Very similar to how we plan/estimate today, except focus is only on a small portion of the project. By estimating # hours as late as possible, we can be more precise as risks pass and uncertainty goes down. Critical Chain Estimating & Scheduling An expert is not someone who gives you the answer, it is someone that asks you the right question. Eliyahu Goldratt (1948- ) (C) 2011 Kevin Aguanno. 38

41 Estimating Hours of Effort Hypothetically, if we run a project over and over again, the random variances in the actual duration of tasks will follow a standard Beta distribution. Note the tail showing worst-case scenarios. Median Likelihood Duration Estimating Hours of Effort (cont d) We normally estimate at 90% confidence, meaning that 90% of the time, our estimate is big enough. If we estimate at 50% confidence, half the time we will have enough time and the other half we won t. Parkinson s Law says that if we estimate at 90%, then most of that time we could have finished much earlier, but the task expanded to fill its available duration. Likelihood Median 50% 90% Duration (C) 2011 Kevin Aguanno. 39

42 Estimating Hours of Effort (cont d) Agile estimating says that we should estimate at 50% confidence at the task level, avoiding buffers on each task, and instead strategically place buffers in the schedule. This is called the Critical Chain Method of estimating/scheduling. Two buffer types: Feeder buffers (when two work streams come together) Project buffers (before key milestones or at the end of the project to protect key dates) These buffers can be much smaller than having buffers on individual tasks Within an iteration, use Critical Chain scheduling with buffers (C) 2011 Kevin Aguanno. 40

43 Why Agile Planning Works If anything is certain, it is that change is certain. The world we are planning for today will not exist in this form tomorrow. Philip Crosby ( ) Why Agile Planning Works Replanning occurs frequently Estimates of size and duration are separated Plans are made at different levels Plans are based on features, not tasks Small stories keep the work moving Work in Progress is eliminated every iteration Tracking is done at the team level, not individual level Uncertainty is acknowledged and planned for (C) 2011 Kevin Aguanno. 41

44 Wrap Up We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Frank Tibolt ( ) Techniques You can Start Using Today Design around Iterative and Incremental Development Immediate, visible, verifiable progress Simplifies solution, lowers risk Increase customer satisfaction Do Just-In-Time Estimating Procrastinate your estimating to reduce risk, improve accuracy, and speed up initial estimating Plan at Different Levels Create plans with different levels of details for different audiences. (C) 2011 Kevin Aguanno. 42

45 Help is Available Agile adoption strategy workshop Agile methodology customization for your organization Agile methodology training (developers) Agile methodology training (managers) Agile health check training for auditors and PMO reps Ongoing mentoring of agile pilot projects Questions? Kevin Aguanno (your speaker) is available for consultation at He is the author of over 20 books, audiobooks, DVDs, and CD-ROMs related to this subject matter: Books: CD-ROMs: Audiobooks: DVDs: (C) 2011 Kevin Aguanno. 43

46 Agile Glossary A glossary of commonly-used terms unique to agile projects. The most prominent definition of each term is used, and where there is debate within the agile community on the meaning of these terms, other definitions may be mentioned. Active Customer Participation Adaptive Software Development Agile Agile Manifesto ASD Backlog Backlog Maintenance Budget Burndown Chart Burndown Chart Burnup Chart Regular involvement by the project sponsor or a delegate and possibly key stakeholders in the day-to-day decision making on the project. One of the key principles of agile management methods. Active customer participation provides transparency, improved customer control, improved customer satisfaction, faster decision making, and faster clarification of requirements. An agile method that applies many agile management techniques to earlier rapid application development methods. See A management philosophy that focuses on delivering value with approaches that are lightweight and responsive to change. A statement describing the core agile philosophy. The original signers of the Agile Manifesto were proponents of several agile software development methods, resulting in a software development flavour to how the manifesto was worded; however, the underlying concepts apply across many different management areas, not just software development. See See Adaptive Software Development. A list of items that have still to be completed. There are several types of Backlogs used in agile methods. See Product Backlog, Project Backlog and Iteration Backlog. The process whereby new deliverables/user stories/features are added to the list of work to be potentially completed during a project; this list is called the Project Backlog. (See also Project Backlog and Product Backlog.) A graph showing the amount of authorized funding (budget) remaining on a project, trended over time. Typically, it is updated once per Iteration to reflect the amount remaining after the actual costs for the completed Iteration are subtracted. A graph showing the changes in a total that represents a quantity remaining, trended over time. It starts at an original value (plotted on the vertical axis), and trends to the right, with the goal of reaching zero as it crosses the horizontal axis. Burndown Charts come in several types; see Budget Burndown Chart, Product Burndown Chart, and Project Burndown Chart. A graph similar to a Burndown Chart that trends data starting at zero on the left-hand side and trends upwards to the right as the number grows over time. See Burndown Chart. Agile Glossary 2011 Multi-Media Publications Inc. Page 1 of 11

47 Chicken Colocation Critical Chain Crystal Methods (Crystal Clear/Orange/Red/etc.) Daily Scrum Defined Method Deterministic Method DSDM A term used in the Scrum method for a project stakeholder who does not have direct control over a project. The contrast for a Chicken is the project sponsor (called Product Owner in Scrum) who is called a Pig. Moving team members so that they are together at one location, allowing the use of face-to-face communications. See also Onsite Customer. A method of preparing task estimates and project schedules that removes hidden contingencies in task estimates and strategically places a portion of those removed contingencies in specific places on the project schedule. Specific techniques are used for sizing these contingencies (called Buffers) and unique metrics are used for tracking the use of these contingencies (e.g. Buffer Burn Rate). See A scalable family of iterative incremental development methods that provides different levels of formality for projects of varying complexity. The simplest, least-formal method flavour is called Crystal Clear and is meant for lower-risk projects with small teams. As team size, risk, or complexity increases, the level of method formality increases, moving through several flavours through Crystal Orange, Crystal Red, etc. See A short daily meeting wherein team collaboration and knowledge sharing are encouraged, issues are identified to management, and commitment is reinforced through the asking of three standard questions. The first question ( Did you complete everything you planned on doing yesterday? ) is about the past and is intended to uncover issues within 24 hours of them appearing. The second question ( What are you going to work on today? ) is to facilitate mentoring and knowledge sharing among team members and also to reinforce commitment from team members. The last question ( Is there anything going to slow you down or stop you from completing your work this Iteration? ) is again intended to identify issues to the project management within 24 hours of them appearing. The meetings are usually held with participants standing up (i.e. no chairs) which encourages the participants to keep the meeting short. See Deterministic Method A method that is based upon a preparing a detailed forecast of the future (estimates and a plan) and then measuring and managing any variances to that plan in order to get the project back on plan.. See Dynamic Systems Development Method. Agile Glossary 2011 Multi-Media Publications Inc. Page 2 of 11

48 Dynamic Systems Development Method Empirical Method Extreme Programming Extreme Project Management FDD Feature-Driven Development Ideal Day IID Increment A method managed by the DSDM Consortium that formalizes earlier Rapid Application Development techniques with a greater focus on the delivery of business value in an iterative, incremental fashion. See A method based upon developing only a high-level plan for the project, getting started, and then monitoring and controlling several variables (such as budget burn rate, quality levels, Velocity, and others) to keep the project s parameters within acceptable tolerance rages. An agile method for solution development that focuses mostly on the technical development work, rather than project management activities. XP was developed concurrently with Scrum, and is most commonly implemented simultaneously with Scrum where Scrum provides the project management processes and XP provides the solution development processes. More information at A term often used as a synonym for Agile Project Management, usually when referring the project management processes that need to be in place to manage Extreme Programming projects. See Feature-Driven Development. An agile method that contains both project management processes and some solution development processes. FDD is notable for its significant guidance and structure for Iteration Zero activities. An agile unit of high-level estimating that assesses work effort for a User Story. Compared to Story Points, Ideal Days have a number of drawbacks: key roles may be missed, the work effort associated with some tasks may be missed without preparing a Work Breakdown Structure first, the estimated work effort may not consider the impact of an individual s skill level or performance, estimates do not typically include the impacts of multi-tasking interruptions, and estimates can degrade in accuracy over time as skill levels improve later in the project lifecycle. Overwhelmingly, the agile community prefers estimating in Story Points over estimating in Ideal Days. See Iterative Incremental Development. A piece of working/completed new functionality that will be added on to an existing base solution. Agile Glossary 2011 Multi-Media Publications Inc. Page 3 of 11

49 Incremental Development Iteration Iteration Backlog Iteration Plan Iteration Zero A classification of solution development methodologies characterized by their up-front prioritization of features and then the building of the features with one Increment being completed every Iteration. One benefit of Iterative Development methods is the ability to deliver business value early as, after several Iterations, the emerging solution may have enough working features to be considered useful for some business purpose. At this point, the project could be terminated, saving time and money, or it could continue adding Increments of functionality until the solution is deemed complete. Another benefit of these methods is a high level of quality due to the ability to put the riskiest elements in early Iterations so that the design can be validated through a Spike, plus the Regression Testing that happens every Iteration. A project schedule will be divided into several Iterations wherein work will be performed that will slowly evolve the entire solution over time. Iterations are managed as a Timebox with fixed start and end dates. A list containing all of the work (expressed as tasks) that needs to be completed during an Iteration. Along with the task name, the Iteration Backlog usually contains a task owner, original effort estimate in hours, and an estimate to complete the task in hours. The tasks in the Iteration Backlog effectively form the Work Breakdown Structure (WBS) for the Iteration. The detailed project plan for the tasks to be performed by the project team members during an Iteration. Iteration plans are developed at the start of each Iteration and are based on the contents of the Iteration Backlog. A complete iteration plan would include a schedule (perhaps but not necessarily shown as a Gantt Chart), a resource plan, and a financial plan but only for the specific Iteration. Higher-level project plans, such as a quality plan or risk management plan are handled at the Release Planning level. The agile term for the first project phase where important pieces of preparation work are performed before a team proceeds through the solution design/build Iterations. Iteration Zero activities include initial high-level requirements gathering, analysis, and prioritization; high-level design; high-level estimating (usually in Story Points), and building the initial Release Plan. Outputs of Iteration Zero include the initial prioritized Project Backlog, the initial Release Plan, and perhaps the Iteration Plan for the first design/build iteration (Iteration #1). Agile Glossary 2011 Multi-Media Publications Inc. Page 4 of 11

50 Iterative Development Iterative Incremental Development Kaizen Kanban Board Lean Development Model Storming Muda Building a product or service over the course of multiple Iterations, with the goal of performing design activities in early Iterations, constructing in middle Iterations, and quality assurance activities in later Iterations. With Iterative Development, features of the solution are completed across several Iterations. The difference between Iterative Development and Linear Development is that Iterative Development provides opportunities for demonstrating work in progress and capturing project stakeholder feedback at the end of each Iteration. An approach to developing a new product or service that prepares a high-level design of the entire solution up front, the slowly builds that solution over time, with functionality being delivered during every Iteration, in order of business priority. Agile methods are Iterative Incremental Development methods, but are more lightweight/flexible than other IID methods such as the Rational Unified Process. A Japanese term that comes from Lean management. See Retrospective. A technique derived from Toyota s implementation of Lean Manufacturing where a signs are used to notify others of the status of a particular production stage. On agile projects, teams often implement this via a Kanban Board which is divided into columns, each column referring to the status of a User Story; for example, not started, designing, building, testing, and completed. User Stories, summarized on Story Cards or Post-It Notes, are moved by the team from one column to another as the User Story works its way through the solution design/build process. The Kanban Board gives a very visible way for any stakeholder to quickly see the status of an Iteration, and it can also be used by the solution development team to signal the next team member in the development process that a piece of work is now ready for his or her action. An agile method that applies the basic principles of lean manufacturing and applies them to product development. A term covering the just-in-time design modeling sessions that agile team members perform throughout the project. In agile projects, detailed solution design is not completed at the start of the project (see Iteration Zero); rather, only a high-level design is completed, and then during the various Iterations of the project, the team members perform the detailed design activities for the User Stories they are developing on a just-in-time basis this is called Model Storming. A Japanese term that comes from Lean management. See Waste. Agile Glossary 2011 Multi-Media Publications Inc. Page 5 of 11

51 Onsite Customer Pair Programming Pig Planning Game Agile methods require frequent interaction with the key business stakeholders who give direction to the team, provide clarification on, make decisions on the spot, and immediately escalate issues. In Extreme Programming, this is called Onsite Customer, with the intent that at least one key business stakeholder is working collocated with the core team members. A quality and risk management technique from Extreme Programming where two programmers are sitting at one computer creating software. One writes the software, while the other looks over his or her shoulder to inspect the newly-written code for defects at the time they are created. Another benefit is that the two can brainstorm alternate solutions to problems, gaining the benefits of the knowledge and experience of both programmers, resulting in a better solution. This technique can apply more broadly to non-programming situations; for example, one could have two designers working together on one design task to ensure that the resulting design was optimal and defect free. A term from Scrum identifying a project stakeholder who has direct control over aspects of a project. Pigs include project team members, the project manager (called Scrum Master), and the sponsor (called Product Owner). The opposite of a Pig is known as a Chicken. See Chicken. A method of estimating the Story Points required to complete a User Story. In the Planning Game, a cross-functional team briefly discusses a User Story with the Product Owner (or delegate) to understand the relative complexity of building the feature. Then, the team members simultaneously turn over cards that have their estimate written on the reverse. By showing their cards simultaneously, the team members avoid the impacts of group think a process whereby a dominant voice (or peer pressure) sways meeker team members into providing the estimate favoured by the dominant members of the group. Using the Planning Game, the voices of dominant team members are allotted equal weight as those of other team members, allowing a brief discussion to ensue to better understand outlying (higher or lower than average) estimates. Once the team has discussed the reasons behind the outlying estimates, the team members once again each turn over a card that reflects their possibly-revised estimate. Over the course of a few estimating rounds, the team will likely converge on a common estimate. Another benefit to the Planning Game is the group bonding and improved cross-functional knowledge sharing that can take place during the discussions of the outlying estimates. Agile Glossary 2011 Multi-Media Publications Inc. Page 6 of 11

52 Product Backlog Product Owner Project Backlog Project Burndown Chart A list of all possible features that could be included in a product over the course of its lifecycle. The Product Backlog may be divided into a number of product versions, each of which will constitute a project and each of which will have its own Project Backlog. The Product Backlog is usually owned and maintained by a strategic business unit such as marketing or product development. The Product Backlog is used to build strategic product roadmaps detailing the product lifecycle. A term from the Scrum method for the business person responsible for delivering value via the project in exchange for a monetary and resource investment. This person may also be known as the project sponsor. In some projects, the Product Owner may delegate day-to-day project interaction and decisions to another business resource such as a business analyst or subject matter expert. A list of solution features and other key deliverables that remain to be completed on the project. At a minimum, the Project Backlog contains a list of the features and other deliverables to be created during the project, listed in priority sequence, along with a size estimate for each, usually expressed in Story Points. The Project Backlog is owned by the business sponsor (Product Owner). Both internal (the core project team) and external stakeholders (Chickens) can add items to the Project Backlog as they are uncovered during the project. The business sponsor will then be responsible for inserting the new items into the Project Backlog at the appropriate level of priority, with some guidance from the core project team (so that dependencies between features are respected). The Project Backlog gets updated frequently throughout the project using the Backlog Maintenance process. In the Scrum method, the Project Backlog is often called the Product Backlog though this is often confusing given the alternate meaning of Product Backlog described in this document. The alternate meaning in this document is the newly-emerging, preferred meaning. A line graph showing a trend line for the total number of Story Points remaining within a project as it changes over time. This total number of points remaining comes from the Project Backlog. The vertical axis reflects the total number of points of work remaining to be completed, while the horizontal axis is divided into the Iteration planned for the project. The slope of the trend line, if extended to the right, will show the number of required iterations to complete all of the scope on the Project Backlog, where it crosses the x axis. In the Scrum method, this graph is often called the Product Burndown Chart but emerging usage tries to eliminate confusion by deprecating this alternate name. Agile Glossary 2011 Multi-Media Publications Inc. Page 7 of 11