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.

1. Agile Release Planning
Michael Geiser

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. 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. 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. 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. Visualize it…
Product Backlog

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. 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. 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. Visualize it…
Product Backlog Release Backlog

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. 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. 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. 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. 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. 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. 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. 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. Visualize it…
Product Backlog Release Backlog Iteration Backlogs
Have you ever heard the expression “slicing the cake” used for this process?

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. Tracking Progress

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. 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. 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. Appendix Material

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