Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Agile Release Planning
Michael Geiser
What is Agile Release Planning
 Agile Release Planning is the process which
 Allows a set of features selected by the Pr...
But that’s not Agile!
“But that’s not Agile!” slides will address common objections to practices
proposed in this deck
Som...
Backlogs
 There are three types of Backlogs to be considered
 Product Backlog: The prioritized list of new features or c...
Product Backlog
 The Product Backlog is the prioritized list of new features or changes to existing features
in a product...
Visualize it…
Product Backlog
Release Backlog
 The stakeholders select the set of features they would like in a Release; this is the Release Backlog
 ...
Release Timeline Estimation
 Once all features are reviewed and User Story estimates are completed, the Project Owner/PM
...
Notes
If this Release
• Starts on 1 Jan
• Has 775 Days if work (+/- 25%)
• Is being worked in by a staff that can
complete...
Visualize it…
Product Backlog Release Backlog
Changes to the Release Backlog
 Product Owners can add or remove scope from a release at any time; they
own the Product a...
But that’s not Agile!
 Waiting to elaborate the requirements until the Sprint begins is
actually an Agile anti-pattern
 ...
Affect of Scope Changes
 Affect of adding 100 Days of additional scope late in the project
 The additional scope will re...
User Stories
 User Stories are estimates of the effort to implement a limited specific item
of work
 Effort is usually e...
Stories Points as a measure of effort have some advantages…
 Without enough detail, it is hard to accurately say “this wi...
Sprint Backlog
 Before a Sprint start starts, the team will select as many User Stories from the
Release Backlog as they ...
Estimating Tasks in User Stories
 Tasks are usually estimated in Sprint Planning sessions.
 Continuous elaboration of th...
But that’s not Agile!
 “User Stories have to be estimated in Story Points; it’s what Agile does”
 There are many agile o...
Visualize it…
Product Backlog Release Backlog Iteration Backlogs
Have you ever heard the expression “slicing the cake” use...
Changes to a Sprint Backlog
 Once the team identifies the User Stories in scope for a Sprint,
changes to the scope should...
Tracking Progress
Release Tracking Chart
The Release Tracking Chart tracks the Scope, Development Plan, Sprint Plan, and Actual Work complet...
Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13
Sprint Close Date 14-Jan 28-Jan 11-Feb 25-Feb 11-Mar 25-Mar 8-Apr 22-Apr 6-May 20-May...
Notes
Shows over time how remaining scope and
velocity determine the code complete date.
Release Timeline Estimation - Cod...
Appendix Material
What is a Fibonacci Series and why are they used?
What is a Fibonacci Series?
 A Fibonacci Series is created by extending...
Nächste SlideShare
Wird geladen in …5
×

Agile Release Planning

1.770 Aufrufe

Veröffentlicht am

Release Planning is a Pain Point in many Agile shops. This is an outline of a process that has worked very well for me over time. I hope you find it useful also.

Veröffentlicht in: Internet
  • Profit Maximiser redefined the notion of exploiting bookie offers as a longer-term, rather than a one-off opportunity. Seasoned users report steady month-by-month profits and support each other through a famously busy, private facebook group. The winner of our best matched betting product oscar has matured into something very, very special. ■■■ http://t.cn/A6hP86vM
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • A 7 Time Lotto Winner Stepped Up to Share His Secrets With YOU ◆◆◆ http://t.cn/Airf5UFH
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • I am very grateful for Jeevan's program because it taught me many techniques on how to overcome common mistakes made in maths. Also, his revision strategy is unique because the same principles can be used in other subjects too and not only maths. Thank you Jeevan, your techniques are very useful!♥♥♥ http://t.cn/AirraVnG
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Your GCSE Maths program has helped me immensely in maths. I am much more confident with this subject and I'm striving for better grades. I really appreciate the time you took in making this program because it has boosted many students self-confidence with their exams. ■■■ http://t.cn/AirrSv7D
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • 8 Ways to Communicate with Your Guardian Angels... ★★★ http://ishbv.com/manifmagic/pdf
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Agile Release Planning

  1. 1. Agile Release Planning Michael Geiser
  2. 2. What is Agile Release Planning  Agile Release Planning is the process which  Allows a set of features selected by the Product Owners evaluated for development effort  Gives the teams an opportunity to understand the product roadmap  Gives Sponsors the visibility to make informed decisions on schedule and budget  The main goals of Agile Release Planning are  Details which teams have work to perform to implement a feature  Create a better estimate on the effort to implement based on an increased understanding of the work to be completed.  Determine and plan for any dependencies between teams
  3. 3. But that’s not Agile! “But that’s not Agile!” slides will address common objections to practices proposed in this deck Some Agile practitioners insist there is no such thing as “Agile Release Planning”: “The end of every Sprint should deliver a Potentially Shippable Increment and you should target to release every Sprint”  This is only realistic in a small number of cases; continual change is disruptive and difficult to support in a Product, especially with many external customers  If the features of Microsoft Word changed every two weeks, would that be confusing to users, difficult to support and reduce the usability of the product? (Yes it would)  Almost all large scale and Enterprise Agile frameworks embrace Release Planning “You can’t dictate progress; the work gets done when it gets done”  The point of planning is not to dictate progress but to estimate times, plan activities for the release and help remove roadblocks or issues before they occur if possible
  4. 4. Backlogs  There are three types of Backlogs to be considered  Product Backlog: The prioritized list of new features or changes to existing features in a product  Release Backlog: This is a subset of Product Backlog selected by stakeholders to be included in a Release.  Sprint Backlog: This is a subset of Release Backlog that a development teams works on during a short time-boxed period (a Sprint or Iteration)
  5. 5. Product Backlog  The Product Backlog is the prioritized list of new features or changes to existing features in a product  The prioritization of this list is set by a single individual who is designated to fill the role of the “Product Owner”.  The Product owner is the proxy for all stakeholders for the project and can change as long as there is only one.  To avoid conflicts and differences of opinion, only the “Product Owner” sets and prioritizes a Product Backlog. Any conflict of prioritization are resolved by the stakeholders by any mechanism that group sees fit.  Product Backlogs are estimated using Feature (or Theme sometimes) & Epic Level estimates  Estimations are “T-Shirt Sizes” (XS, S, M, L, XL, XXL) level with rough estimations in weeks or days (sometimes hundreds of hours) based on prior work and consensus of estimators  Estimations use a Fibonacci Series-like set of ranges for better accuracy  Check if larger estimates can or should be broken down into smaller deliverable units or multiple releases  Teams commonly limit the scope of an Epic to a single release; multiple release use multiple epics
  6. 6. Visualize it… Product Backlog
  7. 7. Release Backlog  The stakeholders select the set of features they would like in a Release; this is the Release Backlog  Release Acceptance Meetings are held where  The Stakeholders review all selected features with representatives from all development and DevOp groups.  The representatives ensure they understand the features and create a “placeholder” User Story because they anticipate work for their group to implement the feature. This helps identify dependencies early.  People with enough experience to accurately estimate work are the representatives but it is a good idea to include as many junior team members as practical to broaden the input an give them experience  Very often these meetings are 2 or 3 hours daily until completed (day-long meetings are less effective)  The Feature must be “groomed” through progressive elaboration enough so that the estimators can understand the work needed to be done. A User Story statement is too vague.  The Product Owner must ensure that the that there is enough detail that meaningful estimates can be made  This requires input from many sources and maybe even development “Spikes” before the meeting  With less detail, the feature can be accepted, but the estimates will only be as accurate as the details  Group Follow up:  Each group creates User Stories to detail the work they will need to do implement this feature.  Any dependencies a group has on a predecessor or concurrent work by another group is documented.  All User Stores are estimated in days. This estimate much more accurate than the original T-Shirt size estimate and from this point on is used instead of the T-Shirt Size estimate.  This estimation effort is time-boxed to a few days.
  8. 8. Release Timeline Estimation  Once all features are reviewed and User Story estimates are completed, the Project Owner/PM completes a “Release Timeline Estimation”  This requires knowing resources allocated and the speed at which they complete work; their “Velocity”  This is the first indication of whether the selected scope will have any chance of fitting into the target of the release  Estimating release timelines from T-Shirt sized estimates are too inaccurate to be useful.  Project Management understands the “Iron Triangle”; and they can adjust the features in Scope, Release Date or Budget (i.e. resources on the development teams) as the stakeholders see fit  They may not adjust the effort estimates. The people with the best knowledge made the estimates.  It is legitimate and acceptable to question effort estimates that seem too large or too small on the basis of “were the requirements understood” not “we want you to do it faster”  If the estimators are not accurate, this will be obvious quickly after development starts because progress tracking of delivered work against estimates provide a feedback loop See the slides on Release Timeline Estimation and Tracking in a separate slide deck for more details and a full release example
  9. 9. Notes If this Release • Starts on 1 Jan • Has 775 Days if work (+/- 25%) • Is being worked in by a staff that can complete 75 days of work in two weeks Then the release work will be completed between 6 May and 15 July Initial Release Timeline Estimation Example Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Sprint Close Date 14-Jan 28-Jan 11-Feb 25-Feb 11-Mar 25-Mar 8-Apr 22-Apr 6-May 20-May 3-Jun 17-Jun 1-Jul 15-Jul Est Scope +25% 968.75 893.75 818.75 743.75 668.75 593.75 518.75 443.75 368.75 293.75 218.75 143.75 68.75 -6.25 Est Scope Remaining 775 700 625 550 475 400 325 250 175 100 25 -50 -125 -200 Est Scope -25% 581.25 506.25 431.25 356.25 281.25 206.25 131.25 56.25 -18.75 0 0 0 0 0 Velocity 75 75 75 75 75 75 75 75 75 75 75 75 75 75 Approved Scope change 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  10. 10. Visualize it… Product Backlog Release Backlog
  11. 11. Changes to the Release Backlog  Product Owners can add or remove scope from a release at any time; they own the Product and the Release scope  From the Agile Manifesto: “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”  But remember: The effect and impact of the scope change on the Release must also be accepted by the Product Owner and stakeholders  Change Control still applies in Agile  Release Acceptance and estimation need to occur before the scope change becomes part of the release  Product Owners and Stakeholders need to realize and accept how their change will affect the Code Complete date change for the Release  Agile SDLCs are not magic; big changes late a release timeline will change the Code Complete date  Consider if the large change can be slotted for the next release
  12. 12. But that’s not Agile!  Waiting to elaborate the requirements until the Sprint begins is actually an Agile anti-pattern  It is called “tiny waterfall” if you go through the steps Define-Develop-Test- Release for each User Story in a Sprint  Agile is about decoupling steps in the SDLC and doing them when they make the most sense; which may be weeks or minutes before development starts  The level of detail of elaboration changes at differ times and fits the reasons for the elaboration
  13. 13. Affect of Scope Changes  Affect of adding 100 Days of additional scope late in the project  The additional scope will require two additional Sprints and changes the code complete date; Project Management “Iron Triangle” still apply.  This is the Product Owners’ decision and the affect of the decision is visible to all stakeholders Effect of adding 100 days of effort on 22 April to Code Complete date
  14. 14. User Stories  User Stories are estimates of the effort to implement a limited specific item of work  Effort is usually estimated in Story Points or Days of effort  User Stories undergo progressive elaboration to add needed details to estimate and describe the work at different times  The sum of the Days or all User Stories in an Epic is compared to the original T-Shirt Size estimate.  The goal is to get a better estimate of effort based on a better understanding of the work and not force the User Story estimate to meet the original T-Shirt Size estimate.  User Story days are a more accurate assessment of effort then T-Shirt sizes should replace the original, less accurate, estimate.  Days of effort are used to slot User Stories into multiple Iterations/Sprints based on the capacity of the team
  15. 15. Stories Points as a measure of effort have some advantages…  Without enough detail, it is hard to accurately say “this will take 5 days”, but you can roughly say, “This bit of work will take twice as long as that piece of work”…maybe.  Comparative effort estimates are generally accurate in this context. …But Story Points also have drawbacks:  They can introduce more complexity and confusion because they are a “unit-less” measure.  They lack business familiarity and clarity when discussing across the enterprise.  They are difficult to normalize across teams due to their abstract nature and different sizing baselines. Best of Both Worlds:  When using Story Points, intentionally choose a baseline task to normalize estimates across teams that has a known or accurately estimable effort.  When using Days of effort, total effort can be estimated since all stories are compatibly calibrated and are easily understood. “Story Points” vs. “Days” Estimates
  16. 16. Sprint Backlog  Before a Sprint start starts, the team will select as many User Stories from the Release Backlog as they feel they can complete in a Sprint  User Stories are usually elaborated to the Task Level in this planning meeting.  This is usually a very short process per User Story if the User Story has enough detail to identify the tasks needed to complete.  The team continues to pull in and elaborate User Stories until the team’s capacity for the Sprint is full.  The team should validate that all identified decencies are completed (or they can Mock the dependency effectively) and that no unidentified dependencies exist.  The team is ready to start the Sprint at this point.  There is no reason the User Stories could not be broken down into Tasks before the Sprint Planning Meeting  If someone is available to do the elaboration, by all means do it if it makes sense (yes, that is somewhat vague)  The team will review and accept or change the tasks as needed when the work is actually started.
  17. 17. Estimating Tasks in User Stories  Tasks are usually estimated in Sprint Planning sessions.  Continuous elaboration of the User Story continues by detailing Tasks.  The tasks for a User Story identifies all the trackable work needed to complete the User Story.  “Development Work”, “QA Work”, “Design Tasks”, “Documentation” and “technical tasks” are examples of the types of work that can be tasks.  Tasks can all be done one person of assigned as the team sees fit; they understand best how to complete the work.  During the Sprint Retrospectives, if the estimates are shown to be inaccurate the team must adjust how they estimate.  If the total hours from the summation of the task effort is different from the original User Story Days effort; the Task estimations are most accurate and the Release Tracking Chart should be updated according and communicated to all Stakeholders.  Some Agile teams to not adjust User Story estimates; Estimates are replaced with actual time to complete when work is completed and total effort is known.  Agile best practices insists that reality is recognized and mistakes corrected so the most accurate information is available; Adjusting estimates when more accurate estimates exist is a good practice to consider.  When the User Story is fully elaborated and fully fleshed out to the task level, you have the best and most precise information on the work; use the best information.
  18. 18. But that’s not Agile!  “User Stories have to be estimated in Story Points; it’s what Agile does”  There are many agile organizations that estimate in days because it offers advantages they value. Prescribing a practice that everyone must use because someone read it on a website is not Agile.  “A single person should pick up a User Story and complete it”  Yes…if it makes sense. Java Developers are very good at writing Unit Tests but other QA tasks require skills the average developer may not have.  If it is more efficient (or otherwise “better”) to have multiple people work on different tasks in a User Story, that’s a good agile practice!  You want to deliver the best code possible; it’s ok if that means splitting work.  “If we have ‘Days of effort’ estimates on Users Stories, we’ll continually hear, ‘You said that would take 5 days, why did it take 6 days?’”  This is a failure to manage expectations; 6 days is pretty close to 5 days and the next two buckets for estimations are “3 days” and “8 days” (so that was a good estimate).  Effort estimates need to be accurate and estimators need give accurate estimates. A feedback loop is the only way estimators can validate their estimates and improve their skills.
  19. 19. Visualize it… Product Backlog Release Backlog Iteration Backlogs Have you ever heard the expression “slicing the cake” used for this process?
  20. 20. Changes to a Sprint Backlog  Once the team identifies the User Stories in scope for a Sprint, changes to the scope should be minimized.  Scope changes in a Sprint are disruptive and reduces the work completed.  If a User Story is blocked and cannot be completed, it should be moved out.  If the team runs out of work, User Stories should be added to the Sprint.  Once accepted, Product Owner’s change to release scope prioritization should only rarely affect the Sprint work.  Work being descoped from the release is an example were this type of change would be considered. The ScrumMaster must agree to the change.
  21. 21. Tracking Progress
  22. 22. Release Tracking Chart The Release Tracking Chart tracks the Scope, Development Plan, Sprint Plan, and Actual Work completed on a single chart that is always available and is always reviewed in Executive Sponsor Status Meetings  Scope:  The Scope and the effort to complete scope constantly changes during a project; normally some scope is added or removed and progressive elaboration gives us increasing more precise estimations of total effort and finish dates  Good Change Management processes for scope is vital; embracing change in Agile does not mean accepting any change without understanding and accepting the impact of the change. Scope should reflect accepted changes by the product owner.  Agile teams should recognize and communicate scope and scope changes to recognize schedule risks take action early enough to compensate for risks and changes in scope or effort.  Development Plan:  Estimated project work that can be completed according to Staffing Plan is charted to compare to Scope  Sprint Plan:  This should track the Development Plan but reflects the actual Staff capacity and highlights immediately when the Development plan is or is not being met so remediation plans can be implemented early when needed  Actual Work:  Shows work completed against Scope, the Development and Sprint Plans. It is transparently communicated when Actual Work completed and total scope are not on plan to met for the target code complete date
  23. 23. Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 Sprint Close Date 14-Jan 28-Jan 11-Feb 25-Feb 11-Mar 25-Mar 8-Apr 22-Apr 6-May 20-May 3-Jun 17-Jun 1-Jul Scope +25% 958.75 886.25 813.75 803.75 760 790 742.5 733.75 718.75 698.75 690 675 665 Scope 775 725 675 675 650 680 650 655 660 660 670 670 665 Scope -25% 591.25 563.75 536.25 546.25 540 570 557.5 576.25 601.25 621.25 650 665 665 Dev Plan 45 95 145 195 245 295 345 395 445 505 565 625 685 Iteration Plan 45 100 150 185 220 265 315 370 440 510 580 650 720 Actual 40 85 120 160 210 240 280 340 425 505 590 650 665 Completed 40 80 120 160 210 240 280 340 425 505 590 650 665 Notes • At any point during the development, the total scope, if the resource plan is anticipated to complete the work and how the actual work is tracking to the plan Project Release Tracking Chart (Completed release) Same graph from 11 March Status Meeting
  24. 24. Notes Shows over time how remaining scope and velocity determine the code complete date. Release Timeline Estimation - Code Complete Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Sprint Close Date 14-Jan 28-Jan 11-Feb 25-Feb 11-Mar 25-Mar 8-Apr 22-Apr 6-May 20-May 3-Jun 17-Jun 1-Jul 15-Jul Est Scope +25% 968.75 843.75 768.75 693.75 531.25 425 327.5 246.25 156.25 81.25 0 0 0 0 Est Scope Remaining 775 675 615 555 425 340 262 197 125 50 0 0 0 0 Est Scope -25% 581.25 506.25 461.25 416.25 318.75 255 196.5 147.75 93.75 18.75 0 0 0 0 Velocity 75 70 60 80 80 70 80 80 75 80 0 0 0 0 Approved Scope change -25 10 0 -50 -5 -8 15 8 0 5 0 0 0 0 Same graph from earlier Status Meeting
  25. 25. Appendix Material
  26. 26. What is a Fibonacci Series and why are they used? What is a Fibonacci Series?  A Fibonacci Series is created by extending the series by adding the last number found to the previous number in the series to find the next number (in the example below 5 + 8 = 13 and 8 + 13 = 21  “Pure” Fibonacci numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144  “Planning Poker” modified Fibonacci numbers: 0.5,1, 2, 3, 5, 8, 13, 21, 40, 100, ∞ Why are Fibonacci Series used?  A Fibonacci Series grows increasing quickly as the position in the sequence moves; the difference between 3 and 5 is less than between 5 and 8 which is less then the difference between 8 and 13  When estimating sizes, repeatable estimations are important; estimators are more likely to consistently rate a User Story an “8” or a “13” but have been shown to change estimations more (i.e. reduce consistency of estimations) when the options are close together like “1”, “2”, “3”, “4” and “5” How are Days and Story Points related?  Using 1 SP = 1 Ideal Day of effort for a velocity of 8 Days per team member in a two week sprint has worked well  Some teams estimate using 1 story point = 4 hours of work and the average team member has a total capacity of 20 Story Points in a two week iteration; 4 hour increments may be too fine grained of an estimation  Everybody must use the same estimations

×