Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Madhur Kathuria Release planning using feature points

649 views

Published on

Agile Tour Delhi NCR2014 - release planning presentation

Published in: Technology
  • Be the first to comment

Madhur Kathuria Release planning using feature points

  1. 1. [ release planning using Feature Points ] Madhur Kathuria, CST,CSC,CSP,CSM Director, Xebia Agile Consulting and Transformation Chair, India Scrum Enthusiasts Community (ISEC)
  2. 2. [ introduction ] 2
  3. 3. [Accidental Agile Coach, Status-quo Disruptor, Transformation freak, Behavioral mystic, nomad, INDIAN] 11 years
  4. 4. 4 [ we will discuss] The principles and values of Agility Traditional vs Agile Release Planning The Product Owner’s Dilemma Estimation Units ̶ Story Points ̶ Feature Points  Using Estimations
  5. 5. [ so what is Agile ?? ] A Process… A Framework… A Philosophy… All Agile processes are necessarily Iterative, but not all Iterative processes are Agile
  6. 6. What Agile Is • Structured and disciplined approach to iterative development • A set of practices that accommodate changing requirements • A set of practices that will significantly improve the quality of your software • An umbrella term for several iterative and incremental software development methodologies. What Agile is NOT • Fly by the seat of your pants development • Getting the same amount of work done in less time • A way for the business to change direction on the fly • A project management methodology • Process: Just for the heck of it
  7. 7. [the Agile Principles] Enablers Support & trust, Technical excellence, Simplicity Results Valuable SW & satisfied customer Harness change for competitive advantage Constant pace Methods & tools Face-to-face Working software as primary measure of progress Self-organizing teams Leading principles Frequent delivery Close communication Reflective improvement
  8. 8. Trust Agile Values Accountability High Performance High aims [agile Values] Sense of Urgency Self Growth and Excellence Goal Driven Approach
  9. 9. [traditional Release Planning]
  10. 10. [agile Release Planning]
  11. 11. [the best way…] PBI1 PBI2 PBI3 PBI4 PBI5 PBI6 … SBI1 SBI2 SBI3 SBI4 … Design Develop Test Deploy Integrate 1-2 weeks Sprint Release Sprint Planning Daily Stand-up Backlog
  12. 12. [a possible new way for large projects] PO Council 4 weeks 4 weeks 4 weeks 4 weeks 4 weeks Planning Sprint 1 Planning Sprint 2 Planning Sprint 3 Planning Sprint 4 Planning Sprint 5 Planning Sprint n DD Sprint 1 DD Sprint 2 DD Sprint 3 DD Sprint 4 Sprint 1 Sprint 2 Sprint 3 Sprint 1 Sprint 2 Sprint 3 Sprint 4 SIT and UAT Sprint 1 SIT and UAT Sprint 2 Sprint 1 Sprint 2 Sprint 1 Sprint 2 Sprint 3 DD Sprint 5 DD Sprint n Release Hardening Ordered Requirements Backlog SIT Team + UAT team Team Backlog Scrum Team (Developers, Testers, Dox, Infra) Team Backlog Team| Backlog Team Backlog Sprint 4 SIT and UAT Sprint 3 MR 1 RC 1 Final SIT and UAT MR 2 FR Planning Team PO PO PO
  13. 13. [estimations] 13
  14. 14. [traditional Estimation] 14  Based on Metric Units (Hours, Days, Months etc .)  Based on Gut feel of the person providing the estimate  Dependent on skill and experience of the estimator ̶ E.g. a seasoned developer might estimate a work to be completed in 5 days whereas a new developer might estimate 15 days for the same work ̶ Who is correct in estimation ?? What happens if in middle of work, the new developer has to take on the remaining work for some reasons?? © 2010 PegasystemsInc.
  15. 15. [boehm’s Estimation Accuracy Graph] 15
  16. 16. 16 Relative Estimation  Does not use traditional metrics based approach (Unit independent)  A Measure of size and complexity of the problem at hand  Even a new bee can estimate provided there is enough knowledge about the problem available But Isn’t complexity experience dependent???
  17. 17. [agile Estimates] [The team estimates the size and complexity of the PBIs] Estimate [Typically, the team would estimate only few top PBIs ( and not all)] [Story Points and the Planning Poker game are a good way to estimate the PBIs]
  18. 18. [the Story Point dilemma for POs] [The estimates come in too late] [Are not common across the teams] [Customers and Sales guys Do not understand Story Points] [Early Story Point estimation are prone to padding and deviations]
  19. 19. 19 [levels of Estimation]
  20. 20. Product/Architecture Backlog Entities Release Vehicle Release Goal Portfolio Product Milestone Release Backlog Epic Scrum Team Story Sprint Theme Feature
  21. 21. [ estimating Release Backlog ] 21  The Product Owner works with the business departments and the development organization to develop estimates (to analyze, design, develop, document, and test the functionality, i.e. whole lifecycle), usually in feature points .  Work with people who will be staffing the project teams to make the estimates. If they aren’t known yet, have people of equal skills and project domain knowledge make the estimates. Do not have experts or outsiders make the estimates. Their estimates are irrelevant to those who will actually be doing the work.
  22. 22. [estimating Release Backlog] 22  Estimating is iterative. Estimates change as more information emerges.  If you can’t get a believable estimate for a top priority backlog item, lower its priority (to delay working on that item until you know more about it). Alternatively, keep them high priority but reclassify them as an issue. The work to turn this issue into required functionality might take ten days; so estimate the issue at ten days.  Lower priority product backlog is vague, a placeholder for further investigation/thinking as its priority increases. The estimates are not very reliable.
  23. 23. [introducing Feature Points] F e a t u r e P o i n t S t o r y P o i n t
  24. 24. [estimating the epics]  Identify 2 epics from the last release and two estimates from the current release which are simple and small  Estimate them relatively based on complexity and size  These become the reference epics for this release  Relatively estimate all epics in current release based on reference epics  Typically you can use higher Fibonacci series numbers at this level e.g. 20, 40, 60, 100, 160 and so on 24 Size of Release = Sum of all committed Epics for the release
  25. 25. [estimating Features] 25  Break down Epics into Features.  Estimate the features relatively (like previous step)  In case the sum of Feature points for features does not match the Epic points, update the Epic estimate with sum of feature estimates. Remember this will change the release size too
  26. 26. [planning Poker Aka Adapted Delphi Wideband Approach] 1. Gather together the customer and the developers. Bring along the story 26 cards. Distribute a handful of blank cards to each participant. 2. The customer selects a story at random and reads it to the developers. The developers ask as many questions as they need. 3. When there are no more questions, each developer writes an estimate on a card, not yet showing the estimate to the others. 4. When everyone has finished, the estimators turn over their cards so everyone can see them. 5. If estimates differ, the high and low estimators explain their estimates. 6. The group discusses it for up to a few minutes, the customer clarifies issues. The developers estimate again write their estimates on cards. In many cases, the estimates will already converge by the second round. But, if they have not, repeat the process. 7. If the estimates differ slightly, reach group consensus on one value. Follow the rule “Optimism wins” (team members whose optimism burned the team once will learn to temper that optimism).
  27. 27. [yesterday’s weather] 27 From: Kent Beck/Martin Fowler: Planning Extreme Programming  Say you’ll do as much today (in the next sprint) as you actually got done yesterday (in the last sprint).  Emergent properties of this rule: ̶ We won’t habitually overestimate our abilities. We have to use actual accomplishment. If we overestimate once, we won’t be able to the next time.  If we are overcommitted, we will tend to try to finish some items in any given time period instead of half finishing them all. It is so embarrassing to tell the customer they can have zero features next time.  On the other hand, if we have a disastrous period, we are guaranteed a little breathing space to recover. ̶ Everyone learns to trust our numbers because they are so easy to explain. ̶ Our estimates automatically track all kinds of changes – changes to the team, new technology, dramatic changes in product direction, etc. The first estimate (at the beginning of the project, when there is no yesterday) is the hardest and least accurate. Fortunately you only have to do it once.
  28. 28. [adjusting Estimates (1/2)] • To reflect any factors that reduce team effectiveness. Scrum assumes an optimal work environment. This activity forces an understanding that suboptimal product factors have a cost. • The guidelines for adjusting estimates to reflect complexity are just that: guidelines. This is not a precise science. • The estimated time for each item can be adjusted by a “complexity factor.” reflecting the degree of complexity due to requirements and technology that will affect the estimates. • Keep adjustment for complexity separate from the base estimate. • Apply the complexity factor only to a known horizon. If it is possible that the team environment will change, don’t apply complexity factors past that horizon. • Diminish the impact of the complexity factors as the team can be expected to master the technical and business domain.
  29. 29. [adjusting Estimates (2/2)] Drag on team productivity – When teams haven’t worked together before, when they are not familiar with the technology, and when they aren’t familiar with the business domain. • Adequacy of working environment – When the team is not together in an open environment with adequate work and conference rooms. Usually a factor of 0.2 • Multiple teams – Due to management and communications overhead caused by multiple teams. Usually an additional factor of 0.1 • Adjusted Estimate = Raw Effort * (1 + complexity factor + drag + working environment + multiple teams)
  30. 30. [sprint and Release Velocity] 30  Based on the mechanism provided on earlier slides, identify the no of FPs all the teams working on that particular backlog were able to complete in their last sprints collectively  This becomes the backlog Feature Velocity per sprint  Based on the feature velocity now you can predict how many epics/ feature can the teams complete in this release or how many more sprints might be needed to complete all the features the PO Wants
  31. 31. [who Does it ?] 31  Epic Estimations ̶ By POs, Product Architects and Senior SMEs  Feature Estimations ̶ Tech Leads, Senior Test Architects, Senior Engineers etc.  Story Estimations ̶ Scrum Team
  32. 32. 32 Scope Progress – Bottom Up Approach Project Epic Feature Stories Project A 120 Epic A 40 Epic B 60 Epic C 20 Feature A 40 Feature B 40 Feature C 20 Feature Points Given by Product Teams/ TLs Story Points Given by Scrum Teams Feature D 20 Story A 50 Story B 50 Story C 60 Story E 25 Story F 5 Story D 45 Project A is 16.7% Done Epic A is 50% Done Feature A is 50% Done Story B is 100% Done
  33. 33. [scope progress – Add Epic] 33 Project Epics Features Stories (WU) Project A 120 Epic A 40 Epic B 60 Epic C 20 Epic A 40 Epic B 40 Epic C 20 Epic D 20 Story A 50 Story B 50 Story C 60 Story E 25 Story F 5 Story D 45 Project A is 16.7% Done Epic A is 50% Done Epic D 20 Project A 140 Project A is 14 % Done Epic A is 50% Done Story B is 100% Done
  34. 34. [principles of Agile Estimation (1/2)] 34  Don’t estimate waste, don‘t look too far into the future. ̶ Estimate up to 2 sprints into the future (fine grain). Estimate up to 2 releases into the future (coarse grain).  Estimate as a team (development + customer). ̶ This reduces the “blame game”, you can no longer point accusing fingers at the person who made the plan.  Estimate your own work. ̶ You feel committed as an individual for the development of the self-selected tasks. ̶ You feel committed as a group for delivering the iteration goal.  Base estimates on facts, rather than on speculation. Use actual data. Use what happened in the past. ̶ Yesterday’s weather, team velocity, triangulation  Estimate early. ̶ Start getting estimates as soon as you write stories. ̶ You will know what questions to ask if you can’t estimate a story. Pa
  35. 35. [principles of agile estimation (2/2)] 35  Estimate often. Learn from experience. ̶ At the beginning of an sprint/ release.  Estimate small features. ̶ Stories of several days up to 2 weeks  Keep it simple. Use simple rules.  Communicate the constraints / assumptions of your estimates rather than just the numbers.  Estimate total effort for implementing a story (development, testing, documentation etc.)  Don’t bring initial estimates (from release planning) into sessions for detailed estimates (iteration planning). Otherwise, the estimators will be tempted to force fit the task estimates to sum to the story estimate.  rack the effort spent and the effort still open until completion. Don’t ask for a percentage. Only count a story as implemented if it has passed the acceptance tests.
  36. 36. Questions??
  37. 37. [if I can be of any help] 38 My space ̶ madhur@indiascrumcommunity.org ̶ www.madhurkathuria.info ̶ Twitter: madhurkathuria ̶ Skype: madhur.kathuria

×