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 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

But that’s not Agile!“But that’s not Agile!” slides will address common objections to practices proposed in this deckSome 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

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)

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

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

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

NotesIf 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 14Sprint 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-JulEst 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.25Est Scope Remaining 775 700 625 550 475 400 325 250 175 100 25 -50 -125 -200Est Scope -25% 581.25 506.25 431.25 356.25 281.25 206.25 131.25 56.25 -18.75 0 0 0 0 0Velocity 75 75 75 75 75 75 75 75 75 75 75 75 75 75Approved Scope change 0 0 0 0 0 0 0 0 0 0 0 0 0 0

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 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

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

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

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

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

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.

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.

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.

Visualize it…Product Backlog Release Backlog Iteration Backlogs

Have you ever heard the expression “slicing the cake” used for this process?

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.

Tracking Progress

Release Tracking ChartThe 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

Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13Sprint 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-JulScope +25% 958.75 886.25 813.75 803.75 760 790 742.5 733.75 718.75 698.75 690 675 665Scope 775 725 675 675 650 680 650 655 660 660 670 670 665Scope -25% 591.25 563.75 536.25 546.25 540 570 557.5 576.25 601.25 621.25 650 665 665Dev Plan 45 95 145 195 245 295 345 395 445 505 565 625 685Iteration Plan 45 100 150 185 220 265 315 370 440 510 580 650 720Actual 40 85 120 160 210 240 280 340 425 505 590 650 665Completed 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

NotesShows 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 14Sprint 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-JulEst Scope +25% 968.75 843.75 768.75 693.75 531.25 425 327.5 246.25 156.25 81.25 0 0 0 0Est Scope Remaining 775 675 615 555 425 340 262 197 125 50 0 0 0 0Est Scope -25% 581.25 506.25 461.25 416.25 318.75 255 196.5 147.75 93.75 18.75 0 0 0 0Velocity 75 70 60 80 80 70 80 80 75 80 0 0 0 0Approved Scope change -25 10 0 -50 -5 -8 15 8 0 5 0 0 0 0

Same graph from earlier Status Meeting

Appendix Material

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