- Scale Scrum to Multiple Teams
- Allow for System Testing
- Evangelize Scale
- Add Cross-Team Roles
- Organize the Work
- Plan the Release
- Keep a Light Hand on the Tiller
- Demonstrate Together
- Report Release Progress
- Review the Release
- Plan a Version Release
New working hardware cannot be delivered every sprint, and when a software team has to balance multiple projects, it often doesn’t make sense to provide a new version of one that often. In some cases, the customers don’t want it that often! Also, many programs in larger companies require multiple teams to contribute to the same software code base and/or systems that include firmware and hardware. Some level of program-level testing is required in those cases to ensure top quality, requiring a stopping point in the development of each incremental version. In any of those scenarios, customers may want lead time to prepare for implementation. Two or three months of predictability may be critical to managing their expectations, and thus their satisfaction. Hence the concept of Agile release planning. Although each sprint must result in stories that could be delivered, for various reasons the business is waiting a number of sprints before releasing them all at once.
A “release” is a set of requirements that take more than one sprint to complete, and the term is also used for the time period in which that set is delivered. In theory a single team could use releases, but in most companies larger deliverables require the output of multiple teams in what I call a “program.”
In Full Stack Scrum™ (FuSS™), you can have two types of releases:
- Planning Release—Work done over a set number of sprints for purposes of predicting delivery, which may or may not comprise a Version Release.
- Version Release—Work delivered to a customer, generally tracked with a new version or model number.
Given the Agile Principle about rapid delivery, the preference obviously is to have each Planning Release result in a Version Release. When that isn’t feasible, a tracking date for a Version Release can be generated, though it is not a waterfall-style “commitment” to either the scope or that date. Rather, it is a data-driven guess generated to satisfy non-Agile customers that require a date.
At the team level, Scrum allows multiple individuals to identify, plan, track, and report on their shared deliverables in a highly coordinated and transparent fashion. Full Stack Scrum does the same for multiple teams. This is referred to as “Agile-at-scale.” Though multiple software teams could release a new version every sprint, in every case I have encountered, the output of multiple teams has required multiple sprints.
Contrary to what you will hear from people with a more complicated system of release planning to sell you, Agile in general, and Scrum specifically are easily scaled up in an organization, and cost nothing but time and discipline to implement. (I don’t claim to be the first to do it; I mentioned Large Scale Scrum or LeSS, for example, in “The Agile Difference.”) Here are how the terms translate in FuSS:
|Concept||One Team||Multiple Teams|
|Work Product||User stories||Epics|
|Velocity||Stories per sprint||Epics per release|
|Facilitator/Coach||Facilitator (“Scrum Master”)||Agile Release Manager|
|Planners||Team members||Guidance Roles|
|Planning Meeting||Planning Ceremony||Release planning meetings|
|Standup||Daily Standup||Joint Demonstration Ceremony|
|Demonstration||Demonstration Ceremony||Joint Demonstration Ceremony|
|Retrospective||Sprint Retrospective||Release Retrospective|
|Overcommitment Check||Capacity Planning||Final Release Planning Meeting|
Like sprints, releases in FuSS:
- Are a set cycle length, as short as possible, four months or less.
- Have a finite amount of work planned for completion, which data shows is realistic.
I stumbled upon a simple truth many years ago: People can handle bad news; what they can’t handle is bad surprises. After I had said that a few times at one company, it spread until I it was quoted back to me by people who didn’t realize they were quoting me! That suggests the universality of the concept. Certainly people became much more proactive in communicating about problems at that company.
A key to Full Stack Scrum is managing expectations via transparency. Since humans cannot predict the future, the only way to match projections with reality is to manage your projections. In FuSS, we do not lie to a customer by telling them something can be accomplished by a given date long before we can state that with high confidence. Instead we practice the level of communication intended in the Agile Manifesto, implemented in FuSS through:
- Frequent contact with the Customer to identify or modify the requirements.
- Invitations to each Joint Demonstration Ceremony.
- Access to the same progress reports your executives can see.
- A contract structured to embrace change.
The Version Release planning process can calculate a “Tracking Date” and use it as a milestone for reporting progress, making clear no commitment to final scope or date is implied. We only name a “Release Date” when highly confident we will hit it. Generally this means two or three sprints in advance, which still beats the reality of most waterfall projects. The customer knows, in real-time if desired, the reason for our confidence, and knows as soon as we do when problems arise.
Under the FuSS approach, the customer may not like the bad news that their desired date can’t be met, but it won’t be a surprise. When they are surprised, it is for the good reason that you deliver more requirements than planned. Or maybe, sadly, the real surprise will be that unlike most suppliers, you actually did what you said you would do!
This major section of the site leads you through the process of using Scrum to plan releases. Bear in mind two warnings.
As previously stated, I do not recommend that teams new to Scrum do so immediately. These add to an already high learning curve, and release estimates will not be accurate until you have a consistent velocity. Combined, those two facts mean the costs outweigh the benefits until you understand Scrum at the team level.
Also, managing multi-team releases is extremely difficult using paper trackers, so much so that I won’t do it. Inaccurate data is highly likely due to transcription errors. When teams are not collocated, significant effort is required to gather the needed data. There is no easy way to identify and coordinate dependencies between teams. For a single team, it’s manageable. In multi-team programs, invest in a digital tracker if you haven’t already. See “The Digital Option” and perform the relevant steps for that section.
⇒ Steps: Set Up Tracker for Releases
Every waterfall project I have been on had something like a “Testing” phase. Some testing occurred all along, but some types were considered impossible to do until all of the development work was finished. In software, the most obvious example, there was a theoretical “code freeze” after which no new functionality could be introduced into the version about to be released. Then full-time testing teams would check to make sure the product worked… as intended… without breaking older functionality or data that might use it. The development teams wait for defects to come in, fix them, and the test teams run the tests again, and in theory the cycle continues until no bugs are found. In practice, I have never seen the code actually get frozen, causing versions to be released late and/or without thorough testing. This results in a lot of finger-pointing about who is to blame for the late releases and quality problems.
In the software world, a lot of effort has been put into fixing the issue by automating most of the testing and running it continuously throughout the release period. This is the right way to go if you can get there. Yet everything I read on the Web and hear in Agile meetings suggests most organizations are nowhere near this ideal. And Agile experts who have only worked in software don’t seem to realize that is a fantasy in many settings where Scrum can be used. When hardware is involved, testing can take months. Equipment that sits outside and/or has electricity running through it faces long testing periods to ensure it can withstand the weather and not kill anybody. A company that produces a lot of options in its physical products must test its firmware and software in every combination, and may have limited test equipment. This can require physical reconfiguration of the test bed. User acceptance testing (UAT) is a part of support and implementation projects, and by definition is done by people not tied to an organization’s Agile goals. Month-end closings and negotiated contracts must go through executive reviews before acceptance.
Since any of these scenarios can leave development teams in limbo, FuSS instead treats those results as defects to be addressed by the normal means. These will be minimal under FuSS due to the emphasis on understanding epics before development and building in quality during. Some approaches to Agile-at-scale kept a waterfall-like “hardening” phase in their release cycles to address these periods, but FuSS instead overlaps the releases in those cases to keep developers driving forward.
For system testing handled by the team that cannot be completed automatically and continuously, determine how long it takes after development ends. Then break your releases into waterfall-like phases with the second covering that number of sprints, but overlapping with the development phase of the next release. One program I worked with needed two sprints to complete its system testing. We broke each release into a development phase of four sprints and two sprints of system testing. The development phase of the next release started at the same time as the final testing phase of the previous release, like this:
Separate testing teams should be Scrum teams and should be testing continuously, catching and reporting as many defects as possible during the Development Phase of each release. Note that defects in this case are considered “escaped” from the development teams; those that get to customers have escaped from the testing teams. This prevents the “QA will catch it” attitude I have observed in some development teams.
The “full stack” concept means, however, that testers should be embedded in the development teams—in other words, there are no separate test teams. In this case, the testers create stories for system testing together, and pull them into their separate team backlogs. As in the case of separate teams, this should be going on throughout the sprint, using system test stories to set aside time in member capacities. During the final testing phase the stories are still mostly for the previous release, and then they shift to the current release. Creating those stories take some time up front, but then you can create templates from them and simply make copies for each new sprint or release.
Those long hardware tests may instead take an entire Planning Release to complete. In that case they will be their own epics, but nothing else changes. Testers, whether on their own or on separate teams, create sprint-length user stories for the work and report negative results as defects the developers must address quickly. Those stories may have a waterfall-like phasing that is unavoidable due to the length, however. A model that has worked well in different settings is to have:
- A story to set up and start the test.
- Small one- or two-task stories to check the test and report any interim data for as many sprints are needed.
- A final story to compile and analyze the data and break down the test apparatus if appropriate.
Notice that each “phase” results in a deliverable, as required of all user stories.
Reviews or testing outside of the program, such as UAT, require no stories! By definition, the team isn’t doing anything, hence there is no need to set aside capacity. If the reviewer/user finds problems, the only time required of the team is that needed to create a defect. The defect then goes through the normal triage and planning process for which you have already set aside time. Of course, the “no escaped defects” standard means the goal is to get zero defects from that process.
Given the misconceptions executives have about project management embodied in “The Waterfall Myth,” I do not recommend trying to implement any method of scaled Agile unless all executives to whom team members report, directly or indirectly, agree to change their own behaviors as needed to support that method. For FuSS, that means the understandings under “Desired Agreements.” The intent is to help them understand how they have to change, not just the people who work for them. This is the line in the sand between merely “doing Agile” and “being Agile.”
You will find this transition easier if you evangelize the scaling effort the same way you did team-level Scrum, if you didn’t do it all at once. The related step sets for release planning refers you back to the same boxes used for that effort. The content narrows to only the concepts relevant to releases, but the process is exactly the same.
By “you” in this case, I mean either the project sponsor or a change champion that person designates to lead the FuSS conversion. The “project sponsor” is the person providing the budget or otherwise considered to have primary responsibility for the success of the project, regardless of official job title. (I’m using the PMBOK term here, but the role might more accurately be called a “program” sponsor in your case.)
The rest of “Plan in Releases” assumes you are working with existing teams and projects. Not true for you? Skip to “Initiate Agile Programs,” and do the steps you need to. Then start any new teams on the appropriate team-level content and come back here when ready to continue with release preparation.
⇒ Steps: Get Buy-In for Scaling Scrum
Some Guidance Roles are specific to multi-team programs. Although these lend themselves to existing job titles, I think it a mistake to simply designate individuals for the Cross-Team Roles. The psychology of someone who enjoys project management may not lend itself to the much leaner facilitation role of an Agile Release Manager, for example. It’s not enough for these people to agree with the desired agreements—they have to believe enough to implement them!
I recommend writing up job descriptions based on the information below and conducting an internal hiring effort. If you don’t find someone enthusiastic about the role, take it external. Don’t have the budget? It may be best for all concerned to release people, and thereby free up their salaries (refer to “Downsides for Some”). Speaking as someone who has gone through the trauma of being fired, I know from personal experience you will do someone who isn’t a fit for Agile a favor by pushing them out to a better future elsewhere.
⇒ Steps: Prepare to Fill Cross-Team Roles
Agile Release Manager
Take what you now know about the Facilitator role, add a little of what the Product Owner does, throw in training skills, and you will have a pretty good idea of what the Agile Release Manager (ARM) does. The key differences are that he or she works across teams the way a Facilitator works across individuals, and facilitates the planning of releases instead of sprints. Specifically this person:
- Facilitates agreements on the release cycle and planning practices.
- Ensures features are identified by the Customer(s) in the format and timing needed by the teams.
- Facilitates Release Planning Meetings to ensure sufficient work is identified and ready for team planning by the start of each Planning Release.
- Facilitates release retrospectives and documents the agreements on cross-team practices.
- Trains and coaches program members on cross-team practices, eliminating the need for program-level Agile coaches added by some other scaled Agile frameworks.
- Is the primary defender of Agile processes from interference by customers, managers, or others in the company.
Like the Facilitator role, in all but the largest programs, this can be part-time as well. By definition, anyone currently serving as a classic release manager in your company will probably convert without issue. That role is often part-time, too, filled by someone doing engineering or testing the rest of the time.
In theory a program, project, or functional manager could make the transition, speaking as someone who has held each of those positions. In practice, unfortunately, people with this background seem to struggle with letting go of the “Iron Triangle,” and their habit of controlling rather than coordinating. Plus, many of the classic program/project management tasks are spread out to groups or pushed lower in the organization. Unless the PM is assigned to three or four times as many units—like a full-time Facilitator guiding three or four teams at once—the PM is likely to do things an ARM is not supposed to do, in an understandable effort to justify their pay.
My typical recommendation to clients is to transfer or hire someone not previously associated with the program, but with some Agile exposure, training skills, and significant facilitation experience. People who have done similar roles using other Agile-at-scale methods, such as a Release Train Engineer from SAFe, are no more qualified than those who haven’t. In fact, I know from many heated discussions that a SAFe fan is likely to resist the parts of Full Stack Scrum that differ. When you interview people about this role, make absolutely sure they can let go of whatever they did before and are willing to follow the system exactly as presented until the Performance Standards are met.
Once the role is filled, have them read any part of this site they haven’t. Besides needing a comprehensive view of the system, they will benefit from knowing the environmental factors working for and against them in your company, as discussed in “Create an Agile Enterprise.”
Traditional functional managers—silo leads like a Product Engineering Leader or Quality Assurance Manager—often resist pure Agile methods for a reasonable reason: They fear for their jobs! After all, if the teams are self-organizing and outsiders cannot assign work, how do the managers add value?
Meanwhile, traditional system architects and analysts wonder what is left for them. They are no longer asked to create a detailed system analysis or technical specification and hand it off to be implemented. How do they now add value?
The answer in both cases is, “Through your subject-matter expertise.” In FuSS these experts, called by the more generic term “architects,” may be asked to:
- Research best practices related to their area of expertise.
- Facilitate identification of, and agreement on, cross-team functional practices based on those best practices.
- Provide formal training and individual coaching on functional practices.
- Drive recommendation and adoption of functional tools (hardware, software, and/or services).
- Provide initial direction and ongoing recommendations on the design or architecture as related to their function, and facilitate and document agreements (per “Agile Architecture”).
- Co-evolve the design and architecture with the teams throughout the project, creating rapid changes to the minimized documentation.
- Help with “make or buy” decisions regarding whether to develop something internally or seek external resources.
- Screen job candidates for the teams to ensure the candidates have the minimum technical skills required for the function.
- If the company uses performance evaluations, provide input on the individual’s functional skills and future developmental needs.
In larger companies, there tend to be two different types of architect, depending on whether they were a functional manager or a system analyst/architect. The traditional functional manager is required by the company to continue the usual functions of hiring and performance appraisal, unfortunately. They usually support people in various teams, and sometimes in both Agile and non-Agile programs. As explained under “Structuring for Agile,” they can continue to do so, but in an Agile way that frees more time for the bullet items above. For people who enjoy the power of their positions, this change can be a struggle.
Most system architects I helped through the transition have reported being happier with the new role, since it affords the fun of collaboration; less wasted planning effort; faster movement from idea to reality; and more hands-on work. As an architecture expert quoted earlier, James Madison, wrote, “An architect should spend as much time as is reasonable physically collocated with the team and product owner to maximize opportunities for direct communication.” The change also reduces work stress because there aren’t people pressuring you to complete a specification—fast—that includes a lot of unknowns. Instead you only have to come up with a starting point that takes a few weeks, after which you will get the same stress-relieving benefits related to schedule that FuSS provides to developers and testers. Finally, mistakes are no longer yours to make. Lots of people will be involved in architectural decisions, meaning the Agile Performance Standard about “no blaming of individuals” applies to you, too!
Few are the companies progressive enough to embrace Agile thinking across the enterprise. Most think of Agile as something only for software development, or maybe for research and development more generally. That means Agile teams must interact with non-Agile groups to get and provide information and/or deliverables. Those groups have little understanding of the impact their decisions will have on deliveries, much less the harm those decisions can do to achieving the Agile Performance Standards.
Wise program sponsors and ARMs thus will recruit Agile Liaisons (ALs) from each of those organizations to perform relevant Customer and Product Owner duties related to their units:
- Provide work requests from their units as epics or user stories, using the correct formats and FuSS processes.
- Provide input into epics and user stories of interest to their units.
- Provide information requested by Guidance Roles and teams on relevant deliverables either in planning or under development.
- Attend parts of Release Planning Meetings, Grooming Sessions, and Planning and Demonstration ceremonies as desired or when requested by the facilitators.
- Funnel work requests from the Agile organization to their units and coordinate those to ensure unit deliveries fit sprint and release performance needs.
I have not found it difficult to recruit people for these positions. In most cases the non-Agile groups were suffering a lot of pain due to lack of coordination with the people creating requirements or the development teams. Rarely have meetings I held with the manager in charge of the function gotten past my description of the purpose before the complaining began about the current state. When I explain that this role and other parts of FuSS are intended to address most of their complaints, I often had more than one volunteer! That is good, because you also want a backup named who can seamlessly fill in for the primary AL when they are absent or busy.
⇒ Steps: Identify Agile Liaisons
Create and Rank Epics
All release planning centers on epics. As explained before, these are simply requirements that provide a larger function or feature over two or more sprints (see “Epics”). They are written in the same format as user stories and get the same kind of grooming, though by the cross-team roles, Customers, and POs instead of team members. They cover the same types of requirements: user, market, business, and technical. Like stories in a Product Backlog, they are rank-ordered against each other for prioritization. This is done in a “Release Epic Backlog,” a list in the tracker the ARM creates that shows all epics assigned to a release. Prior to the Final Release Planning Meeting, they are only “proposed” epics; after that, those that remain are “planned.” The only sizing required is that an epic must be small enough to complete within one Planning Release.
Before the first Release Planning Meeting of your first FuSS release, the Customers and Architects must have created enough epics to potentially keep the teams busy for the length of the release. The stories to deliver the epics in a particular release are created later by the teams and collected within its “Release Backlog.” Each epic’s stories form its “Epic Story Backlog.” A team that does release planning uses either of those backlogs to create its Sprint Plans instead of pulling directly from the Product Backlog. That is, the stories in each are rank-ordered and the team draws from them during the Planning Ceremony. Don’t get too hung up on all of these backlog types; the relevant steps use the generic word “backlog” for whichever type the team is using.
The Release and Epic Story backlogs can be revised by moving stories back and forth with the Product Backlog, rewriting the stories, deleting them, or re-ordering them. But unlike the Product Backlog, which can contain stories that may never get done, the goal for the Release Backlog is to empty it—that is, to complete all of the stories in all of the epics during the Planning Release.
Organize a Portfolio
A relatively new feature in Agile tools, though it has existed in project management tools for years, is a portfolio management function. This allows creation of nested categories of work, called “portfolio items,” that roll up from lower to upper levels. For example, each team’s stories and standalone defects attach to epics; all epics could combine into “Products”; and all products into “Strategies.” That way a picture of overall progress is provided at whatever degree of granularity a manager or executive needs.
Portfolio items are held in one-to-many relationships. This means a higher-level category can have multiple categories underneath it, but each of them belong to only one higher-level item. For instance, a grocery chain might use this hierarchy for a program to improve its supply chain for individual products:
“Food” is the program, and “Vegetables” and “Fruit” are projects. Notice that “Food” can be “Fruit” or “Vegetables,” but “Fruit” can only be “Food” (not “Paper Products,” for example).
In at least one tracker with this feature, the categories can be rank-ordered. Combined, these features make a portfolio management tool a powerful means of implementing strategies, prioritizing competing projects, and tracking progress across teams.
FuSS does not require a portfolio hierarchy. However, larger companies with multiple product lines, especially where multiple teams contribute to the same project, will gain a competitive advantage in efficiency by choosing a tracker with this capability and using it faithfully. Then come up with a single scheme across the organization for at least the top-level sets of categories. This becomes the means for the organization’s leadership team to convey and rank-order strategic initiatives, and Customers to do that with the levels used in implementing those initiatives. It eliminates the logical absurdity that “everything is #1,” a mindset that invariably causes significant conflict, duplication of effort, and wasted labor hours as people are yanked from project to project.
Here’s an example of a portfolio hierarchy showing portfolio items above and below an investment management Web site called “Wealth Manager,” the “Product” (Level 3) in the table below:
|1||Strategy||Company-wide investment category||Commercial Sales||Leadership Team|
|2||Program||Multi-product initiative||Benefits||Program Mgmt|
|3||Product||Deliverable sold to customers||Wealth Manager||Product Mgmt|
|4||Epic||Set of functions marketed to customers||Investment Picker||Product Mgmt|
|5||User Story||Small user or back-end function||Fund search||Product Owners|
The Wealth Manager is one of several products in the Benefits program, itself one of several programs which support the Commercial Sales strategy.
Since managers are the primary audience for the progress data in the middle layers, it makes sense to work across organizations to build consensus on what types of items should appear at a given level. The Marketing Department and Design Group might have radically different types of items they consider “Epics,” but both have deliverables of that size they can link to the Wealth Manager portfolio item. An advertising campaign for the company as a whole is not technically a company product, but it is a deliverable with customers—the top leadership team—so why not refer to it as a “Product?” In the table above, you’ll see that the heads of the company pick the initiatives; middle managers work out the middle three; and the teams via their Product Owners have final say over the bottom level.
The “minimally releasable product” or MRP is the smallest set of epics that will result in a useful deliverable to end users. A Version Release will include the MRP at minimum, and preferably some additional functionality that pleases customers, plus continuous improvement epics. Only the tiniest software or nontechnical projects will provide a finished product in one Planning Release, though they can provide new versions in each Planning Release. The MRP is “good enough” for end-user testing, marketing demonstrations, early adopters, or whoever needs an early look at a functioning product.
In a warehouse redesign, the MRP might be a fix to the 20% of causes we believe cause 80% of our problems with safety or efficiency, per the Pareto Rule. The MRP can be implemented right away, which will in turn provide feedback for future iterations.
For a new Web site, the MRP might be a fine-looking site with minimal content and navigation. The customer has accepted the proposed layout, graphic types, fonts, and colors and added enough pages, links and navigation to go public. On the other hand, if you are developing a new digital toaster for another company to sell, the MRP might be a 3-D model and bill of materials taking several Planning Releases to develop.
The Customer(s) must identify the user and market requirements for the MRP. The other Guidance Roles then add the “must-have” business and technical requirements without which those user and market requirements cannot be released. Your tracker should provide one or more ways to designate the MRP options, such as a Version field or a Tags/Labels function. Each Planning Release will be made up of MRP and continuous improvement efforts. With luck, in the last Planning Release of a Version Release, you will have extra capacity to work on epics that add value for the customer or get a jump on the next Version Release.
In FuSS, 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 stories without significant help.
- Phase 2 planning begins, in which the meetings continue with the Product Owners invited, who drive further clarification and details until:
- One or more teams has volunteered for each epic.
- The POs 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 POs hold a Final Release Planning Meeting to:
- 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, 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 Plan to stakeholders, consisting of the epics planned and the release’s end date.
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. The planning cycle starts during Sprint 2 (S2) of Release 3 (R3), the first cell that says “Weekly” in it:
|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 POs 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 POs to break free for desperately needed Phase 2 meetings! On releases that have problems, the psychological drive to meet the deadline would cause some teams to delay or skip those 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 they 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 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.
My entire career in project management, teams have expressed confusion about what they are supposed to be doing. 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.
For FuSS, 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, Product Owners 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 PO Consensus On…|
|2||Epic statement (“As a…”)|
|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 FuSS 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. Now dozens, if not hundreds, of labor hours have been wasted. While that benefit is probably common to all Agile-at-scale systems, FuSS 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 PO consensus is required to meet the Definition of “Ready,” teams via their POs have veto power to force clarification of requirements. Thus ends the complaints mentioned at the start of this section!
- Review the Epic Backlog
- Groom an Epic
- Review Acceptance Criteria
- Address Epic Dependencies
- Address Epic Risks
- Shift to Phase 2
- Finalize Proposed Epics List
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.
- 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 POs are crystal clear on what will happen during the Final Release Planning Meeting described 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 was a way to communicate to stakeholders that this would not be a normal sprint with normal deliverables.
FuSS 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
Though this can be a difficult in your very first release, after that there will always be regular development work the team knows it needs to do. For instance, an epic from the previous release may still be going. Even after your program has matured in Full Stack Scrum, 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 his or her sprint tasks. By that point in the release some next-release epics will be “Ready.” Teams can claim them through their POs, 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 work.
The Agile Release Manager (ARM) sets a Final Release Planning Meeting with the Release Planners and POs. 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 PO 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
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.”
- The velocity of each team, using the method described under “Count on Success.”
Caution: 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 task hours 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 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.
Download the 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 have five sprints left!).
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
Start the meeting by showing the spreadsheet results, like these:
The Justice League is in good shape. They came up with 55 stories in 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 POs 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, you can run them past the epic requester to see if he or she wants them, and go for it in this release if so.
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 safe 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 scope. 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.
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 FuSS program, there is little for the ARM to do but run the Release Planning meetings and coach the Release Planners or Facilitators as needed. The Facilitators handle most of the coaching across 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. 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 Agile.
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, but again, any problems should have been raised as blockers that get addressed by the 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 Stack Scrum with zero negative impact. 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
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 POs 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 FuSS, 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, “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?”
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 attendees 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 standard 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.
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
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 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, this spreadsheet results 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 adds 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.
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 previous sprint 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
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 POs 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
The Version Release is a semi-Agile way to answer executives who require you to provide a date beyond the end of the next Planning Release. Because that date, or the scope, or both, are guaranteed to be wrong, FuSS creates them with as little effort as possible, and makes no “commitment.” Instead it provides a “tracking date” against which progress is measured. You can legitimately reassure executives this is a data-driven estimate—probably more of one than they are getting from waterfall programs in the company, because I rarely see those go through the disciplined planning processes PMs are trained to do. Assuming you hit the 80% predictability standard for those releases, the Tracking Date will be 80% accurate for the length of your last Planning Release. That is easily as confident as any waterfall project manager can claim to be of the actual release date three 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. 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.
Along those lines we borrow and modify a standard project management concept called “contingency time.” After a project plan is drafted, waterfall project managers typically add a percentage of extra time to the duration. In other words, if the project is expected to take 18 months, the PM will add from two months (10%) to as high as nine months (50%) to the schedule. FuSS instead adds 20% more epics on top of the MRP. These are labeled as “Extras” when created. For planning purposes, you can just add 20% to the MRP count instead of actually drafting the Extra epics.
Similar to the Release Epic Backlog, you will need to create a Version Backlog that filters on the field you use to designate the MRP. I recommend a single dropdown list with these three values:
- “None” or blank
At the end of each Planning Release, you will update the Tracking Date if need be. Usually, it goes further out, again based on the data. An advantage of this system is it is incredibly simple to explain to executives why, based on basic math.
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 Tracking Date would be the end of the fourth release after the teams can start working on the project. Here’s the math:
- 152 (MRP) + 38 (20% Extras) = 190.
- 190 ÷ 54 = 3.5, rounded up to 4.
Programs new to FuSS must rely on a longer-term version of a classic project management technique called “Ideal Days” estimation. This involves the Release Planners and POs 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.
- Prepare for Version Release Planning
- Run the Version Release Planning Meeting
- Communicate and Update the Tracking Date
 Madison 2010.
 Cohn 2010.