Contents
Facilitate Planning
- Keep a Light Hand on the Tiller
- Demonstrate Together
- Report Release Progress
- Retro the Release
- Plan a Version Release
Facilitate Planning
Plan Continuously
Process
In FuSca, release planning is continuous and iterative, just like development work. We minimize team involvement so they can remain focused on creating working deliverables, yet still ensure a clear understanding of the next set of requirements before work begins on them. Requirements going into a Planning Release can change up to the day before the release starts. After that they are subject to the same discipline as user stories during a sprint, to reduce the damage done to progress by context switching.
At a high level, here’s how it works in a large multi-team program:
- Customers, Architects, and Agile Liaisons continuously create epics for future Planning Releases.
Note: With the Agile Release Manager as facilitator, those three roles make up the “Release Planners.” Like the Facilitator on a team, the ARM is also a “voting member” of the group. 
In the second sprint of a release, the Release Planners begin rank-ordering and grooming epics for the next release.
Note: This begins “Phase 1” planning.- They meet at least weekly to repeat Step 2 until they think:
- They have enough epics to keep the teams busy in the next release.
- Those epics are detailed enough that the teams can break the epics into sprint-sized requirements without significant help. (I’ll call these “user stories,” but feel free to substitute any term[s] already in use in your workplace.)
- Phase 2 planning begins, in which the meetings continue with the Team Guides invited, who drive further clarification and details until:
- One or more teams has volunteered for each epic.
- The TGs agree the goals in Step 3 were met.
Deadline: The last day of the current release. Epics may not be added to the new Release Plan after then.
- During the first sprint of the new release, in addition to continuing normal development work, each team drafts all user stories for all epics they chose.
- At the end of the sprint, the Release Planners and TGs hold a Final Release Planning Meeting to do the next two steps.
- They compare the number of stories a team created to its “Release Capacity”: The number it completes in a sprint (its velocity) times the number of sprints in the release cycle.
- If there are too many stories given the number of remaining sprints, they either:
- Trade epics or some stories in them to other teams with Release capacity left, or
- Remove the lowest-ranked epics.
Goal: No team is overcommitted for the release.
- The ARM communicates the Release Backlog to stakeholders, consisting of the epics planned and the release’s end date, emphasizing this is not a scope “commitment,” just a “best guess based on what we know today.”
In the second sprint of a release, the Release Planners begin rank-ordering and grooming epics for the next release.
Release Cycle
To help you visualize the release planning process, here is a sample schedule. Assume the program completes four sprints per release. We’ll skip ahead to plan the fourth Planning Release, starting in Sprint 1 (S1) of Release 3 (R3):
| Sprint | R3, S1 | R3, S2 | R3, S3 | R3, S4 | R4, S1 |
| Meeting | R3 Final Release Planning | R4 Phase 1 (Weekly) | R4 Phase1 (Weekly) | R4 Phase 2 (Weekly) | R3 Final Release Planning |
The Release Planners come up with their proposed R4 epics during S2 and S3 (Phase 1 Planning). During S4 they invite in the TGs to check the epics and volunteer for them on behalf of their teams (Phase 2 Planning).
You may wonder why the Final Release Planning happens after the release has started. I would prefer to do it the previous sprint, but have bowed to reality. The meeting cannot succeed if the teams don’t take up to a labor day from their sprint to draft the story list for the next release. During the last sprint of a release, teams are focused on finishing as many epics as possible. I have found it hard to get just their TGs to break free for desperately needed Phase 2 meetings! On releases that have problems, the psychological drive to finish as many epics as possible would cause some teams to delay or skip those critical story drafting meetings.
So I moved the exercise to Sprint 1. Fortunately, it does not seem to slow forward progress. Because the epics are clear and rank-ordered by the start of the sprint, teams can create and begin development work on some of the stories. They can meet to draft the remaining stories on whatever schedule they prefer, without stopping forward momentum. And the Release Planners still get done with the Final Release Planning in time to give advance warning of requirements that probably will, or definitely will not, be delivered.
If manual system or regression testing is required that no one team can do by itself, figure out how to overlap the releases as detailed under “Allow for System Testing.”
In a fully agile organization, you can simply match the end of the release to the end of its last sprint. However, some companies insist on calendar-based release cycles even when their teams are agile. You can conform while remaining agile by making commitments based on the last sprint of the any team (that is, the last Joint Demonstration Ceremony) within each of those periods. In a company on a quarterly release cycle, you would simply plan your scope based on the sprint end date nearest the end of the quarter. The sprints shown in the sample schedules in the “Team-Level” section end on May 26, 28, and 29, any of which would be fine for a May 31 quarterly release date. For the last two examples, both of which are on two-week sprint cycles, you might even use the previous sprint end dates of May 14 and 15 as the last ones associated with the May 31 release, for extra cushion or to allow for bug-fixing. Note that under any of these schedules, the next Agile release would start before the deadline date. Stories in the associated sprints would count toward the next quarterly company deadline (August 31), even though work on them would start before May 31.
⇒ Steps:
Epic Grooming
Throughout my career in project management, teams have expressed confusion about what they are supposed to be doing (when I first arrive, that is!). This is typically due to lack of detail in the requirements; ongoing arguments over priorities; or both. The goal of release planning is to eliminate that lack of clarity.
In FuSca, epics are groomed exactly the same way teams groom stories during their grooming sessions: A group discusses each in detail, asking questions and blocking the item when answers are not immediate, until the group feels it can break the item down into the steps for completion. At the release level, the “group” is the Release Planners instead of team members. They might take Sprint 1 off, but otherwise attend mandatory meetings weekly to groom the epics. Follow the guidance under “Get the Story Right” in terms of the discussions required and content desired on each epic card. There are effectively only three differences:
- Instead of making sure stories can be done within a sprint, you make sure epics can be done within the release.
- Unlike story grooming, in which you create a draft task list, you do not create a draft story list for the epics, though you can create stories to address specific concerns (like risks that need mitigation).
- Toward the end of the process, Team Guides are brought in to volunteer for epics on behalf of their teams and drive further clarification of the requirements.
Remember that teams can share epics just as they can share stories. It is best for one team to take the lead, but they can reach out to other teams or individual contributors for help. This is how you can move work to teams instead of re-forming teams for each batch of new work, and still cover any skill gaps.
As at the team level, grooming discipline is imposed by setting a planning deadline. Each epic proposed for a Planning Release must meet the following “Definition of ‘Ready'” prior to the start of Sprint 1, or it does not make it into the release:
| Release Planner and TG Consensus On… | |
| 1 | Rank order |
| 2 | Epic statement (“As a…”) |
| 3 | Epic title |
| 4 | Acceptance criteria |
| 5 | Dependencies |
| 6 | Size: Epic is small enough to complete in one release |
| 7 | Team(s) volunteered to do the epic |
| 8 | Technical details sufficient for the team(s) to draft stories without further description |
The numbering is not sequential; rather it reflects the order in which planners have typically reached agreement in planning sessions I have witnessed. Often, a change in any one item causes a change in other items in this list, just as happens to stories. Debates often erupt over what the epic is “really” about at items 5, 6, and 8, which in turn forces the planners to rewrite items 2–4, which in turn may cause a re-ranking! The decision at any point that the epic is too big creates a big stir as it gets broken into smaller ones that must be groomed quickly.
One of the key benefits of FuSca for team productivity happens in this planning. It’s one thing to have the Release Planners spend an hour debating an epic. It’s quite another to have the development team spend a sprint or two developing a poorly groomed epic, only to have the requester say during a Demo that the team is not doing what that requester intended. In that case dozens, if not hundreds, of labor hours have been wasted. While that benefit is probably common to all Agile-at-scale systems, FuSca also eliminates time wasted during the “big room planning” some use, where teams get involved before the requesters have nailed down what they want.
In effect, because TG consensus is required to meet the Definition of “Ready,” teams via their TGs have veto power to force clarification of requirements. Thus ends the complaints mentioned at the start of this section!
⇒ Steps:
- Review the Release Backlog
- Groom an Epic
- Review Acceptance Criteria
- Address Epic Dependencies
- Address Epic Risks
- Shift to Phase 2
- Finalize Proposed Epics List
Set the Critical Sprint 1
Draft the Stories
A story I verbally call the “Sprint 1 Exercise” goes into that sprint for each team each release. Here is some “starter” wording you can modify as needed:
- Title—Draft stories for release epics.
- Statement—As epic requesters, we want to know whether our epics are likely to be delivered in this release, so we can accurately manage our customers’ expectations.
- Acceptance Criteria—In each epic proposed for the release, the team has drafted all stories the team thinks will be needed to complete it, including story statements and acceptance criteria.
- Notes:
- Create “must-have” stories only, those absolutely required to meet the epic Acceptance Criteria.
- Assign the stories to the new release as you create them.
- Make copies of recurring stories for each sprint.
- Move “nice-to-have” stories to the Product Backlog or to a possible epic you create for the next release.
- Only those stories likely to get into the next sprint will be groomed, per your normal grooming cycle.
- Stories may be added, deleted, or revised later in the release.
- Goal is to set initial technical direction for each epic and prevent overcommitment at the start of the release.
The first time out, the ARM should ensure TGs are crystal clear on what will happen during the Final Release Planning Meeting detailed a few sections down. It is critical that all teams complete their Sprint 1 exercises during the sprint, coming up with lists as complete as possible given what they know at the time, for all chosen epics.
Choose a Direction
Another point to Sprint 1 is taking time for any upfront design the team needs. On any new epic, there can be a host of unknowns. The questions I hear team members ask after the requirements are clear can be summed up with, “How are we going to go about this?” Until some agreement has been reached on that answer, you run a significant risk of wasting time: People with different ideas on that answer may work toward different solutions without knowing it. Think of each Planning Release as a mini-project, and you’ll realize mini-versions of project problem can recur.
Waterfall answers this by taking many weeks, or months, to plan out and design the project in detail. Unfortunately, a large amount of that plan and design becomes inaccurate due to all the changes we’ve talked about. Agile-at-scale thinkers came up with a middle ground between the extremes of “dive right in” and “plan it all” with something referred to as “Sprint 0.” In some methods this was intended primarily for research and architecture spike stories. The “0” designation communicates to stakeholders that this would not be a normal sprint with normal deliverables.
FuSca attempts to further increase productivity through continuous, “just-in-time” research and design incorporated into Release Planning, Grooming Sessions, and Sprint Plans. Nonetheless, part of Sprint 1 should be answering any remaining questions team members have about the technical direction of their epics. You can do this through some spike stories, and research tasks within stories. Forge agreements on the design you want to try first and explore technical issues that need to be resolved before you can dive in. This usually results in changes to the draft story lists for the epics and less chance for overcommitment in the Release Plan.
Keep on Developing
After Sprint 1 of your very first release, there will always be regular development work the team knows it needs to do in later releases. For instance, an epic from the previous release may still be going. Even after your program has matured in Full Scale agile, the relevant Agile Performance Standard allows you to miss on delivering some epics. Usually their stories get assigned into the new release, so you just keep working on them during Sprint 1 as already planned.
Teams that complete all of their epics will pick up new high-ranked ones to work in the backlog exactly the way an individual works out of the backlog when done with sprint tasks. By that point in the release some next-release epics will be “Ready.” Teams can claim them through their TGs, create and groom initial stories using the normal team-level processes, and start working them. During Sprint 1, they merely draft the rest of the needed stories for those in-progress epics.
The Sprint 1 exercise is #1 in the backlog as you go into the Planning Ceremony, followed by defects from the prior sprint and then spike stories for the new release. After those, go ahead and fill up the rest of your Sprint 1 Plan with existing development or continuous improvement work.
Finalize the Release Plan
Schedule the Meeting
The Agile Release Manager (ARM) sets a Final Release Planning Meeting with the Release Planners and TGs. Ask the teams to “front-load” their Sprint 1 exercises, and if they agree, schedule the meeting toward the end of Sprint 1. Otherwise hold it no later than Day 1 of Sprint 2.
Ask any TG who says they cannot attend to forward it to the Facilitator or another team member who can. This meeting is important enough that if any team will not be represented, you should reschedule the meeting up until that last date.
⇒ Steps: Schedule Final Release Planning
Prepare Data
Some data you need will take time to gather. ARMs planning their first release can skip this paragraph for now. All others, start by moving the stories from any epics left incomplete in the last Planning Release. An alternative is to move the epics themselves, but be sure you record somewhere your Epic Acceptance Rate—the percentage of epics planned for the release that got done. The point is, make sure any unfinished stories still important are moved to the new release, if not their epics, so they will be counted in the release capacity checks. Handle their priority like any others in your Release Backlog. By that I mean, don’t assume those epics are still a higher priority than the ones getting proposed.
Obviously, you need to create the release in your tracker, meaning the placeholder for release epics, stories, and defects. Typically there is a specific field in the tracker for this, where you make up a name and enter the start and end dates. In cheap options you might have to create a “tag” or “label.”
Next determine:
- The velocity of each team—the number of requirements (packages, tickets, etc.) the team reliably produces within a sprint or relevant time period. For example, a Kanban team might use “cards per week,” which you can then translate into a “per-sprint” figure if needed.
Caution: For Scrum teams, use story counts even if your teams use story points. Otherwise the teams have to size the stories in advance, a waste of time for each story that gets deleted or significantly changed later in the release. (For other reasons, see “Why use story counts instead of story points?“) - The total number of stories the teams created.
In a digital tracker, you can probably assign the stories to the release, and then run a report or create a list that shows all stories filtered by release and team. Then just count! If not, export a CSV file of all stories with those two fields, and filter by them in a spreadsheet program.
Despite the request in the “Sprint 1 exercise story” template for people to assign stories they create to the release, I have found it necessary for the ARM to double-check. Look at all stories assigned to each release epic and make sure the teams did so. Almost invariably I find some—and sometimes many—stories that would have been left out of the over-commitment calculations if I hadn’t.
I have not found it necessary to account for standalone defects separately. Per the Sprint 1 exercise story, the team should create copies of each of its recurring stories for each sprint. That includes stories for fixing older defects. Newer standalones, if common, have already reduced the team’s velocity, so in effect you would be double-counting them. One or two random ones won’t have a big impact on the math.
Modify the Release Capacities Spreadsheet
Download the FuSca Release Capacities spreadsheet. Complete these columns with the data described:
- Team—List each team name.
- Velocity and Stories—Enter the figures from the previous section.
- Sprints—Expose the formula and change the “5” to the number of sprints remaining in the Planning Release in all of that column’s cells (unless you use six-sprint releases!).
It will return these values:
- Sprints—The number of sprints it would take the team to complete the stories it drafted at its normal velocity (stories divided by velocity, rounded to whole numbers).
- Plus/Minus—The number of sprints left in the release minus the “Sprint” figure, meaning if it is:
- A negative number—How many more sprints the team would need than there are available to get that number of stories done.
- A positive number—How much excess release capacity it has in terms of sprints.
- Zero—The numbers balance out.
⇒ Steps: Prepare for Final Release Planning
Run the Final Release Planning
Start the meeting by showing the spreadsheet results, like these:
The Justice League is in good shape. They came up with 55 stories across all of their epics, and their velocity is 12. Since 12 divided by 55 is 4.58, that rounds up to the number of sprints remaining (5). The “0” in their last column means they are not overcommitted.
The Guardians of the Galaxy have some excess capacity. The “1” in their last column means they could take on one extra sprint’s worth of work. That’s good, because the Avengers are in trouble. Their “-2” means it would take two more sprints than remain in the release to do all the work they have identified.
The ARM’s first move is to ask if an epic the Avengers claimed, or at least some of their stories, could be taken by the Guardians instead. Then maybe the Justice League could take a few stories. Of course, if the other teams don’t have the necessary skill sets, reassignment may not be possible.
My bet would be that the lowest-ranked of the Avengers’ epics must be removed from the Release Plan. Occasionally I have allowed TGs to argue for a higher velocity number, perhaps because of an upwards trend the last couple of sprints, or because the team decided to write smaller stories during the exercise.
What I will never do is let the team remove stories from the epic, just as I do not let an individual who is over capacity for a sprint reduce their time estimate for a task. Remember that the Sprint 1 story mandates “must-have” stories only. Removing stories from the epic should mean the epic will not work.
Also, as with sprints, remember that teams can always work out of the backlog if they 1) finish all of their epics, and 2) cannot help other teams on incomplete epics. By the time they reach that state, the Release Planners will have at least a few fully groomed epics at the top and “Ready.” Or if some “nice-to-have” stories have been identified during the course of the release, you can run them past the epic requester to see if they’re still wanted, and go for it in this release if so.
Communicate the Release Plan
As soon as the meeting is over, the ARM is ready to send out the Release Plan. All it comprises is the epics and the end date of the release. The ARM will save some time in the long run by thinking through every person who could possibly care about what will be released, and including those people on an e-mail with this information. This reduces the odds of your having to answer the same question over and over.
The best possible scenario is to create a report showing this information in your tracker, and give each of those stakeholders “viewer” access to the report. That way they can not only access real-time information anytime, they can drill down for details without bothering anyone.
Next best is to export that information to a location everyone can reach, like a wiki or network share folder. In either case, include a link to the location in the e-mail. In the worst case where you cannot create a digital location accessible by all stakeholders, include the story statement and maybe the Acceptance Criteria for each epic in the e-mail. The hope in this paragraph is that people wanting that information in the future will go look it up instead of bugging you about it!
Along those lines, I strongly urge you to include a disclaimer making clear the plan is not a scope “commitment.” Otherwise some executive is going to get upset when all of the epics are not delivered. First, of course, there is a lower Performance Standard rate for epics than stories. Also, like stories in a sprint, an epic could be reduced or removed if deemed unimportant. We are trying merely to predict the amount of work we will deliver, not the specific work. Taking all of this advice together, here is a sample of the e-mail I send:
When a link to the epics isn’t possible, replace the “access the epics” sentence with the bullet list of planned epics. I don’t recommend a numbered list, because that will imply a priority order to stakeholders that doesn’t really exist anymore. We are trying to deliver all of the epics, and the rank-ordering during the Release Planning might be radically different by the end of the release.
⇒ Steps: Run the Final Release Planning Meeting
Keep a Light Hand on the Tiller
I am a (very) amateur sailor, with a 15-foot boat I like to say is “almost as old and ugly as I am, but just as functional!” My sailing instructors taught me that with your sails trimmed correctly given the wind and desired boat direction, the boat will mostly take care of itself. Over-reacting with the rudder to every small change in conditions will slow you down, because the sails will constantly be in less-than-ideal positions. Instead, “keep a light hand on the tiller” and let the boat correct itself until a major wind change occurs or you make a course change. I view the ARM role that way. Intervene heavily on a regular basis, and you will do more harm than good.
During the mid-release sprints in a mature FuSca program, there is little for the ARM to do but run the Release Planning meetings and coach the Release Planners, Team Guides, or Facilitators as needed. The Facilitators handle most of the coaching in the program, with the ARM “coaching the coach” when questions or issues arise. Most blockers are handled by the Facilitators of the teams involved, or preferably the team members who are blocked. The ARM only gets involved when the Facilitators can’t fix them, primarily blockers external to the program. As you’ll see, progress reports will only be updated sprintly and stakeholders are trained to look them up.
The rest of the time, the ARM needs something to do, which is why I recommended earlier this be a part-time position in all but the largest programs. In organizations still addicted to waterfall thinking, the ARM tends to get invited into a lot of unnecessary meetings more appropriate to a classic program manager. Unless directly and personally ordered by a big-shot to attend, just say “no.” The fact your name is one in a list on a meeting invitation is not a reason to attend a meeting not appropriate to agility.
Some Agile organizations hold “Scrum of Scrums” meetings in which the Facilitators gather as often as daily to discuss stories on which they are cooperating. The equivalent of an ARM facilitates that meeting. In every case I have heard about, these turn into status meetings, so they aren’t really “scrums.” Everyone should have “view” access to every other team’s section of the tracker, taking care of status. Only teams with dependencies should have anything to say to each other on a given day, which they could do without everyone else being there. Some Agile writers describe this as a “problem-solving” meeting instead of a classic scrum[1], but again, any problems should have been raised as blockers that get addressed by the members or Facilitators of the teams involved.
Hence I think a “Scrum of Scrums” is an inefficient use of ARM and Facilitator time, and have left it out of Full Scale agile with zero negative impact to the system’s predictability. The remaining goals of those meetings are easily handled by “face-to-face communication” per the Agile Manifesto plus one other change: the Joint Demonstration/Review Ceremony.
⇒ Steps: Support Facilitators
Demonstrate Together
Address Scaled Communication Problems
The Joint Demo/Review solves several problems suffered by multi-team projects:
- Stakeholders for more than one team find it difficult to attend each team’s Demo. The teams are usually on similar sprint schedules, which means the ceremonies overlap.
- After initial “big room” planning of releases in other Agile-at-scale methods, there are no opportunities for most members of the teams to interact directly, and identify new risks or program-wide improvements as a group.
- Related to the previous point, a “Scrum of Scrums” only gives TGs and/or Facilitators insights into what other teams are doing. The Joint Demo approach provides all team members with:
- Better understanding of the architecture as it evolves.
- Ways other people have solved technical problems the member might be facing.
- Unfiltered stakeholder input regarding the entire project.
- More eyes to identify potential blocking dependencies between teams, epics, or stories.
- More eyes to provide input on the member’s work or team’s direction.
In FuSca, the ARM schedules a recurring Joint Demo once per sprint cycle, using the preferred cycle length if the teams involved are on different cycles. That is, if most teams use a three-week cycle, schedule the meeting to align with the last day of most team’s sprints, every three weeks. Mandatory attendees are the members of all teams and all Guidance Roles attached to the program. Kanban teams and individual contributors supporting the Scrum teams can participate and demonstrate as well.
Also invite the Project Sponsor, interested executives, stakeholders, and external customers even if they will never attend. Combined with providing access to your tool or sprintly reports, you thus protect yourselves from the accusation of “hiding problems” and cannot be blamed for any surprises an outsider doesn’t like. I have more than once had a tough conversation with an executive end well after I pointed out in effect, “With due respect, you have never attended the Joint Demos or informed me you could not access the tracker and reports. All the other stakeholders knew this problem existed, and an e-mail from me would get lost in the hundreds you receive every day. What else was I supposed to do?”
⇒ Steps: Schedule Joint Demonstration Ceremonies
Give Each Team its Time
Each team takes turns doing everything they would in a single-team Demo, though on a shortened schedule. For cycles of two weeks or less, allow 15 minutes per team. For three- or four-week cycles, you may need to bump that as high as 30 minutes. Remind stakeholders they would be asked to spend that much total time regardless. A Joint Demo just makes it easier for them to attend (and saves a little overhead that would be duplicated in separate meetings).
In each turn, the team shows the results of all sprints completed since the last Joint Demo, and demos any stories completed, regardless of the related sprint dates. This honors self-organization by allowing the teams to be on different cycles. A team on two-week sprints might thus show the results of two sprints if most teams are on a four-week cycle. Note that the number of stories will be roughly the same as the team would do on the more popular schedule.
As discussed in the section on team-level Demonstration Ceremonies, only stories that have already been accepted, or which the team is requesting acceptance of during the Demo, may be demonstrated. Then the team shows their backlog for comment on content and rank order. In this setting, this may be the Release Backlog filtered to their stories, or they can go epic by epic. If they are already in their next sprint, they can instead show their current Sprint Plan. Encourage team-specific input from all attendees throughout the Ceremony.
Assuming your tracker has a Release Burndown Chart (or you can update the spreadsheet described below on the fly), display it after the last team is done. The ARM then closes the meeting by asking for concerns or questions about any aspect of the project, progress, or process. These may result in stories for the current release, new epics for the next release, or action items the ARM needs to track. Anything okay for the teams to address in their own ways should be left to their self-organizing efforts during their Retros. The ARM can follow up to ensure that happened without asking for specifics.
Kanban teams and individual contributors can be asked to participate in the Joint Demo if they have dependencies with the Scrum teams. The only significant change is they will report on the WIP Limit Performance Standard rather than the sprint delivery standard. Just like the Scrum teams, they will show the list of stories accepted since the last Demo; demonstrate any stories of special interest to attendees; show their backlog; and invite input from everyone.
Drive Epic Acceptance
When all stories in an epic have been completed, the ARM asks the requester to accept that epic. This can be during the Joint Demo if there is time left. Otherwise, follow up after the meeting. Everything relevant to user stories under “Accept the Acceptable” applies to epics, except objections will be recorded as standalone defects attached to the epic. Those must be tackled starting in the next sprint, and once cleared, will result in an accepted epic.
⇒ Steps: Run the Joint Demonstration Ceremony
Report Release Progress
Create a Release Burndown
Just as it is for sprints, the Burndown Chart is the most powerful tool for tracking release progress. At this level, it shows the number of stories assigned to and accepted in the release instead of the task hours in the sprint.
I hope you have chosen a tracker that provides release charts. Among other benefits, you can skip to the next section now, “Send Sprintly Reports.”
The rest of you can download the FuSca Release Burndown Chart spreadsheet and:
- In the first “Sprint End” column, enter in the:
- First row—The date of the Final Release Planning Meeting.
- Remaining rows—The dates of each Joint Demo during the release.
- After the Final Release Planning Meeting, under “Stories,” in the first row, enter the total number of stories in the release.
Example: See the table below. - Create a bar or line chart from the table, selecting for the data source the two columns and all rows including the still-empty ones.
- Add a “trend line” or “slope.”
Note: This is either a static “ideal burndown” line as discussed in “Review the Burndown,” or a line that moves to predict the delivery date. Your spreadsheet tool may use a different name.
After each Demo, determine the remaining number of stories in the release and update the spreadsheet, like this:
With a predictive trend line added in Microsoft Excel, that spreadsheet resulted in the following burndown chart:
The bottom end of a predictive line will shift after each sprint. In the figure, the line crosses the “0” story line slightly before the Release End Date of June 16 (and Excel added a “−20” hash mark). All is well! Obviously, if it is crossing 0 past the end date, it’s time to investigate team-level progress for undeclared blockers.
Send Sprintly Reports
With luck, all of your project’s stakeholders will have easy access to your tracker, attend your Demos, and be willing to check progress on their own. In many organizations, however, waterfall-style status reports are still required. And if your stakeholders are not willing to check progress, your ARM will waste a lot of time responding to redundant requests for information. Proactive reports are a relatively low-cost way of avoiding this.
My practice is to update, after each Joint Demo, the tracker or shared-location report from the Final Release Plan announcement with:
- A one-paragraph summary of how the Joint Demo went.
- A general description of the completed stories.
- Bullet lists of statistics (story acceptance rates, standalone bug counts, etc.).
- The Release Burndown Chart.
Then I send an e-mail to stakeholders with a link to it like the Final Release Plan announcement, repeating the summary there since that’s all most of them will care about.
Should your bosses insist on weekly reports, between Demos you can simply report on the Sprint Burndown Chart and maybe list any stories that were already accepted that week. Then do the more comprehensive report after the next Demo as that week’s report.
⇒ Steps: Report Release Progress
Retro the Release
Though not a formal team, the Release Planners have just as much to gain from this Agile principle as any other group of workers: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Either hold a short additional meeting, or invite the TGs to the start of the first planning meeting for the next release. Answer the three questions from the Sprint Retrospective Ceremony modified to apply to releases. Cover both the Release Planning process and cross-team interactions during the release. Take a look at previous Retro results to see if you implemented the desired changes and how they worked.
You can refer to “View the Sprint in Retrospect” for details, but here is a reworking for releases of the sample questions there:
- What went right?:
- Did the percentage of accepted epics go up?
- Did the Customer have nice things to say in the Joint Demo?
- Were problems in previous releases avoided or reduced this time around?
- Were there specific examples of teams helping each other in new ways?
- Did changes to the release planning process work as hoped?
- What went wrong?:
- If you did not reach the 80% standard for epic acceptance, why not?
- Are there planning practices the team used that did not seem to add much value for the effort?
- Did any of the Release Planners feel especially stressed? When and why?
- Did teams blame each other for problems?
- What blockers arose that the ARM had to address, and how could you prevent that type in the future or clear them quicker?
- Were there problems with stories shared between teams?
- What can we do differently?
- For each “went wrong” answer, what caused the problem, and what is the solution?
- Is it time to change a process, or do you want to wait another release to see how it goes?
- Do you need to be more conservative during the Final Release Planning Meeting?
One other difference I suggest for Release Retrospectives is not keeping the results confidential. They affect everyone in the program, so I think it makes sense to record them someplace everyone can see and comment on them.
⇒ Steps: Review the Release
Plan a Version Release
Create a Version Backlog
A long-term “roadmap” of features or products is not part of Full Scale agile, because its scope, and any associated dates, are guaranteed to be wrong. However, executives may require you to provide one. The Version Release Plan is a semi-Agile way to meet that demand which I hope you never use. Better to convince the requesters they are slowing down those involved while adding zero value for the enterprise, as detailed in “The Agile Difference.”
If that fails, simply break the Product Backlog into a top-priority group with as little effort as possible, and make no “commitment.” Each Version Release aligns with the end of a Planning Release. You can legitimately reassure executives this is a data-driven estimate—probably more of one than they are getting from waterfall projects in the company, because I rarely see those go through the disciplined planning processes project managers are trained to use. Assuming you hit FuSca’s 80% predictability standard for those releases, each Version Release date is 80% accurate for the length of the last Planning Release for it. That is easily as confident as any waterfall project manager can claim to be of the actual release date a few months out.
For version planning, the Release Planners do the equivalent of a Sprint 1 exercise, except drafting all of the epics required for the version instead of all the stories for an epic—the Version Backlog. A version may or may not complete the MRP. For this purpose, I make an exception and require only the story statement, not Acceptance Criteria or anything else. That’s because we do not promise those specific epics, since customer satisfaction is more important. When—not “if”—the customer or market or technology changes direction, you are going to change direction. Again we are trying to predict the amount of work, not the specific scope. We don’t want to waste any more time than absolutely necessary on predicting the unpredictable future.
Similar to the Release Backlog, you will need to create a Version Backlog in your Agile Tracker. In this longer-term scenario, you are more likely to finish your MRP and have capacity left at some point, so it is okay to identify extra epics that could get done to add value for the customer. This backlog thus should filter on the field you use to designate the MRP. I recommend a single dropdown list with these three values:
- “MRP”
- “Extra”
- “None” or blank (meaning, too unlikely to bother with at this point!)
Estimate the Releases
After your program has run through a few Planning Releases, you will have an “epic velocity” that makes Version Planning easier. That is the number of epics the program reliably delivers each Planning Release. Then you just do the same math used when determining whether the program is overcommitted for a Planning Release, only dividing the total remaining epics by epic velocity to figure out how many Planning Releases would be required “given what we know today.” So if the teams together deliver at least 54 epics per Planning Release, and the Release Planners came up with 152 MRP epics, the version would require four planning releases after the teams start working on the project. Here’s the math:
- 152 (MRP) ÷ 54 = 2.8, rounded up to 3.
- 3 (Planning Releases) x 54 = 162 (epic capacity)
- 162 – 152 = 10 Extra
Programs new to FuSca must rely on a longer-term version of a classic project management technique called “Ideal Days” estimation. This involves the Release Planners and TGs making an educated guess at how much calendar time those epics would take if that was the only thing the program did. They then add time based on non-project time demands and translate that to the number of Planning Releases.
⇒ Steps:
↑ Plan in Releases | ← Prepare to Scale | → Initiate Agile Programs
[1] Cohn, M.(2010), Succeeding with Agile: Software Development Using Scrum. Addison-Wesley: Upper Saddle River, NJ.