Over a million developers have joined DZone.

Agile Release Planning: Getting to a Shared Understanding

DZone 's Guide to

Agile Release Planning: Getting to a Shared Understanding

If your release planning is going slower than expected, consider that everyone simply might not be on the same page.

· Agile Zone ·
Free Resource


How often are you satisfied with the speed, timing, and results of your release planning activities? What remains a mystery and what works for you? This paper describes what was learned over an 18-month journey of wrestling with how to effectively prepare for release planning. How do we define "effective" in our context of a small number of Agile teams working on a single product backlog?

We believe our learning and planning is effective if we can plan quickly, start on a path, and have a resulting delivery that meets our desired business outcomes in a projected timeframe that, on average, does not vary beyond acceptable limits. Our finding is that having a lightweight Discovery and Estimation Process that is centered on individuals and interactions with the teams doing the work results in effective release planning. It is a flexible process that is disciplined, heightens collaboration, builds understanding, uses techniques that fit the new work, and, when timed right, avoids a “Sprint 0.”

Agile planning is always a question of balance in not taking too long or going too deep or starting so soon that any projected forecasts are significantly off-base. Revisiting decisions is common, and the team doing the work has a cloudy vision of what they are building and why. The right balance minimizes the delay in the start of the work, which leads to learning about what you are creating and adapting to more accurate plans.

This paper focuses on how to prepare for your release planning session in smaller organizations with a small number of teams and features. The goal is to provide an initial shared understanding of why, what, and how to identify risks and infrastructure tasks, and create a rough forecast of the effort to build the Minimum Viable Solution (MVS). With this information in hand, the initial release planning can happen quickly. These principles could be applied in larger settings; however, this paper is based on the learnings of trying this approach multiple times in a small Agile organization with 3 teams or less.

Our model has the objective of doing the preparation for release planning closer to the middle than the end of the current release in short sessions using common Agile techniques and feedback loops to improve the model. This allows a short release planning session where the team is leaving with an initial shared understanding built over a few weeks that has allowed teams to let the information sink and develop a deeper understanding at about the same effort as a two-day planning session. The results so far show surprisingly accurate forecasts and an increase in shared understanding and team happiness. It is the shared understanding and team collaboration that are key here, as adapting your plan is inevitable for complex products.

Principles Behind the Process Steps and Tools

These are the principles that act as a foundation for the typical steps used. The steps and tools may vary depending on the type of work, the technologies used, the current related domain knowledge that the teams have, and the complexity of the work.

  1. Replace “requirements delivery” with “requirements discovery,” with the entire development team, Product Owner, and key stakeholders collaborating on the what and the why of the solution being built. The development teams build more understanding of their customer’s needs and pain points while also using the knowledge of technologies and architecture to discuss alternatives, risks, and unknowns to create a view of the “how.”
  2. Many of the steps are short time-boxed meetings spread over time in the team’s mornings, leaving them the entire afternoon for sprint goal work. This approach fosters focus on just enough detail and allows the “spacing effect” and time for reflection. That is information spaced over time is better remembered.
  3. The teams hold retrospectives on the process steps and tools immediately after completing to generate a list of future improvements and understanding what worked well. A small team of volunteers drives change in the current process and tools that is reviewed with the teams to apply in the next release planning cycle. The team should own how the process works and feel empowered to constantly adapt to what works for the team and organization
  4. Use well-known Agile practices wherever possible to follow successful Agile planning that others have pioneered.

Process and Tool Overview

The process consists of up to 8 types of sessions that typically last one to two hours with the Scrum team and some outside observers and participants. The sessions start with the “why,” moves to the “what,” and creates an initial view of the “how” to allow crude sizing of the work. The result is a shared understanding of the work as a big picture with a layer of high-level details. The result can be input into Release Planning Session with the stakeholders that expedites the initial planning of the release that will require the usual inspection and adaption of the plan to achieve the desired business outcomes.

Most steps involve the team members in discussions and creating outputs with those outside team acting mainly as observers, with some exceptions depending on the organizational structure and roles. For example, if there is a separate architecture team, their role may dictate involvement in discussions that relate to the current system design, solution alternatives, and constraints.

Discovery and Estimation Framework Assumptions

  1. This process is designed for new features and products that require complex, adaptive work. Adding simple changes on top of other features or making minor changes to existing operations do not require the overhead of this model. These types of changes could be better served by some exploratory testing perhaps combined with code examination, review by Subject Matter Experts, or being discussed and flushed out within your Release Planning session. That is any new work should be viewed through several lenses to judge which steps provide value in the process. For example, answering some questions like about the work's similarity to previous work or the team's domain experience with the work will guide the selection of the necessary steps. 

  2. There exists a gating process that reviews business opportunities for fittin in the company’s vision and its ability to deliver a possible solution. Architectural constraints, required technologies, and identified or created common vocabulary can be used to discuss the work. Before engaging the Agile teams, the Ideation deliverables are completed, and the organization must identify the specific teams that will undertake this new work.

  3. The goal is for the process to start no later than about 2-4 weeks before the final sprint of the current release. At this time, the refinement effort for the current release should be lower, allowing space for much of this effort. This approach more easily allows valuable software being delivered in the first sprint of the next release.

Preparation Before the Process

There is not a single recipe for the tools used and the required steps, as each piece of new work must be reviewed based on what is known before this process starts to gauge which steps of the process are necessary and which steps may not create valuable understanding. A small group meets to ask the following questions to help create the initial plan which steps will be executed.

  • Is the work complex?
  • Is the work completely new to the team or similar to past work?
  • Do the team(s) have domain experience with the work?
  • Is the team building on an existing code base, building new or a combination of both?
  • Is the scope considered minor or a major initiative?
  • Is the team familiar with the technologies, tooling, and any current implementation?
  • Is the work primarily user-facing or “backend”?

Using the results of reviewing the new work, a decision is made whether or not the assigned Scrum teams will require either research sessions or hands-on testing sessions with existing products to understand the essence of the new work. This preparation is for either work requiring changes and technologies not supported by the current product platforms or hands-on session for learning about a related existing solution that needs modification. The research session goal is to briefly survey existing solutions in other companies to understand overall solution approaches and understand the terminology. The hands-on session goal is to gain basic understanding of the how and what of the related solution that exists within our product portfolio.

The teams also review team norms for the processes (scribing, use of laptops, how they prefer to capture information) and make transparent any concerns they have about the upcoming work and scheduling of the process. Creating an initial schedule of the process steps, reviewing the attendee lists with other members of the organization, and reviewing the timing of the process and its projected impact on future sprint goals sets expectations and reduces surprises. If the required effort crosses the typical effort for refinement sessions, sprint goals must be reduced. The schedule is regularly inspected and changed to reflect the actual progress and requests from the teams and extended team members.

Process Steps

Step 1 – Customer Need and Feature Vision

Presenter: Product Owner (PO) or Business Analyst (BA) - Typical Time Box: 1 hour

This session focuses on the customer need or problem, the product or feature vision, desired business outcomes, key scenarios, basic personas, and known constraints that came out of the Ideation Process. The solution or feature goal is defined and clarified through this discussion. The goal is to describe the "what" and "why," not the "how." Sample stories or diagrams can be used to step through conceptual workflows as a starting point. The teams will review and refine the vocabulary list started at Ideation or create a new vocabulary list. Depending on scope, complexity and Ideation deliverables, this step could require more than one session and include demonstrations of current solutions of relevance.

Step 2 – Story Writing Workshop

Facilitator: Scrum Master or team member – Typical Time Box: 2 hours

To develop a deeper understanding of the customer need and discover solution possibilities, the team holds a story writing session to create user and system tasks/goals in quantity, not worrying about quality as a free-flowing idea stream for each persona that was identified. Note that if the work focuses on system-to-system and API “interactions,” the team could use an alternative format to write “cards” such as Feature cards [COHN-2].

These “cards” serve as discussions and collaboration to start to build the shared understanding among the team. This is the team’s initial view of what is possible for the feature that is developed along with Product, Architecture, Technical Support, DevOps and other extended team roles to create a set of one-liner “stories” or “features” written on the front of cards. On the back of a card, list any discovered acceptance criteria, risks, impediments, high-level tasks ,and links to team or infrastructure sub-tasks required to support the goal. The sub-tasks and any parking lot issues are captured as you go. The team identifies any stories or technical stories that need discussion with PO/BA for prioritization. These are stories with technical value that help speed up delivery and are important to do early to mitigate risk or as part of a known process/event, or a known dependency, where a critical story needs some other work done beforehand. Discussion occurs around MVS and areas of learning or validation with customers that are required as the product is being built.

Step 3 – Creating the Big Picture

Initial Story mapping– Scrum Master or team member – Typical Time Box: 2 hours

For user-facing product deliveries, this session creates a story map based on the expected user experience from start to finish, allowing combining, refining, adding or subtracting from the initial brainstorming session [PATTON]. For “system” features, this step is replaced with conversations around a decomposition of all tasks that must be fulfilled to accomplish the desired business activity. This approach, Feature-Driven Development, uses small pieces of work that represent “features.” The collection of features comprise what is required to deliver the “business activity” and the map focuses on the sequence to building the solution.

Through a series of conversations among the team looking through the feature flow from a user’s or system point of view based on different personas, the team creates low-fidelity prototypes of the UI as necessary for shared understanding, look for gaps, identify what is essential to the user, what the priorities among stories are, and come to a common understanding of the big picture. The PO leads a discussion on what the MVS is for this release to meet the desired business outcome. The final dividing line for this release and possibly one or more future releases is the result of collaboration between the PO/BA and the development teams. The resulting ranking of stories provides not only perceived value,but it may alsoy focus on special business outcomes like early demos, targeted learning, trade shows etc.

Step 4 - Possible Design Approaches

Facilitator: Team Member - Typical Time Box: 1-2 hours

The team brainstorms on design options and high-level tasking to create an initial view of system design and architecture considerations for the required work. The team uses agreed-on design session guidelines to focus at a higher level acknowledging the design will emerge over time as the work proceeds and not attempt to definitively pick the actual design and corresponding details up front. The team discusses possible principles of the application design, database design, and technical services using some combination of idea visualization such as sequence diagrams, activity diagrams, and database diagram at the conceptual level. Or the team may use other communication techniques such as drawing out workflow or process steps.

Members of the architecture team attend to determine and communicate with the team on possible deviations from already formed views on the technical roadmap and maintain any architectural constraints. In turn, the team may present a case that the roadmap is not the best path that may require follow-up and agreement before proceeding. This preparation is the key to the next phase happening smoothly in discussing more about the how by having the team understand the work involved in implementing specific design approaches.

Step 5 – Speed Estimation

Facilitator: Scrum Master or team member - Typical Time Box: 1 hour

The team uses the “Speed Estimation” relative sizing technique to size stories into “t-shirts” effort buckets. Each card is reviewed for the current expectation of the required work and compared pairwise to each other card to iteratively map in different effort buckets. The result will be sizing of what is known about the entire feature at this point to help development recognize what work fits within the release timeframe. The team uses a 1- or 2-minute time box and then votes on sizing with the majority ruling. At the end of the comparisons, the team has an opportunity to move a card to a different bucket after giving a reason for the move. There is an unknown size category for tasks with significant uncertainty for later consideration so the process continues moving.

Step 6 Speed Estimation Checking

Facilitator: Scrum Master or team member – optional – Typical Time box: 30 minutes

The results of speed estimation are double-checked by selecting a well-understood, medium-sized story and doing development and QA tasking on the required work. The teams estimate how long each task will take and look at how that work flow would be over time. That cycle time is compared to the cycle times of previous releases for a medium sized story. If the results are significantly different, for example, 50% bigger, the team holds an additional review of speed estimation results for possible adjustment.

Step 7 Create and Review the Initial Release Forecast

Facilitator: Scrum Master or team member – Typical Review: Time Box 30 minutes

A volunteer from the team uses speed estimation results for the MVS to considers story pointing comparisons to previous releases, reviews possible cycle times of t-shirts sizes from past data, and summarizes the risks, open issues, key infrastructure sub-tasks, and any additional information that surfaced during the previous sessions. Using the MVS, historical and sizing rules based on studies of other Agile software projects, the volunteer creates a range of the number of sprints based on current team composition to complete the work [COHN-1], [WATTS]. The results are compiled in one sheet page for discussion with the product team. The supporting information that generated the estimate is discussed within the development team for their input and buy in. These details are agreed to by the team though remain private to the team to discourage the typical “negotiation to a smaller estimate” phenomenon by putting the estimate under an intense scrutiny that occurs in many organizations

Step 8 Review of The Initial Release Forecast with Product

Facilitator: Scrum Master or Agile Manager – Typical Time Box: 1 hour

The purpose is to insure there is a clear understanding of the initial work forecast for the MVS including risks and unknowns. The group discusses potential changes to the work, what needs to be demonstrated and validated along the way, plans for a demo to learn or validate, and revisit the MVS list, story ranking and story mapping if necessary. The result is input to the overall release plan that accounts for all other known agreed to work.

Process Follow-up

After creating the initial forecast with the team, schedule a retrospective with all participants to gather information on current process, the steps used, their feeling of the created shared understanding as a team, and how to improve. The retrospective results in preliminary information of what to change. We ask for volunteers to join a facilitator to consider options and discuss the feedback in more depth to create a list of specific changes to bring to the team for review and buy in. These steps reinforce the concept that the team own the process and have the power to change it to make it more effective. Once the teams agree to changes, we update our process, try it out on the next work, stream, and continue to refine it. We also note any impediments that slowed us down for help from the organization. For example, having a product roadmap could provide more guidance as we start out and prevent the team from considering in depth options and scenarios that don’t fit the initial solution vision.

As the sessions occur, record the artifacts and session length and dates to allow generating cycle time and total effort data as input into the retrospective process.

Effort and Results Data

The cycle time and effort are used to plan sprints toward the end of the release to allow sufficient time to run Discovery and Estimation while still providing value to the release under construction. The goal is the start the next release first sprint with work refined and ready for sprint planning.

Table 1 – Discovery and Estimation Related Data

Process Iteration

Cycle Time - Days

Total Time - Hours

Type of Work

Forecasted Sprints

Actual Sprints

# Process Changes







NA-initial trial







NA-initial trial







NA-initial trial




































* Forecast caused change of release goal, reduced scope, and/or additional staffing

** Significant change in scope and direction occurred during construction


  • Process Iteration – Version of Discovery and Estimation process applied to a new work stream built by one or more teams.
  • Cycle Time – Number of elapsed business days from the initial session (Step 1) to the creation and review of the forecast summary (Step 7).
  • Total Time – Number of hours each team spent in the sessions covering the initial session (Step 1) to the creation and review of the forecast summary (Step 7).
  • Type of Work – Categorization of the work that influences the steps required and the techniques used within the steps.
    • Greenfield – a new stream of work that is not constrained by prior work
    • New – stream requires all new code/module in an existing product or to integrate existing products.
    • Similar – stream is different though similar to a product or feature in the company’s catalog of solutions
    • Retrofit – stream requires selective changing and extension of an existing solution
  • Forecasted Sprints – The Range of Sprints required to deliver the functionality defined by the MVS with a specific team or group of teams.
  • Actual Sprints – The number of sprints required to deliver the MVS plus any additional scope added while constructing the solution along with any other work that get prioritized for the release after the forecast is created. “NA” means that the work forecasted was significantly different that the work ultimately delivered making the comparison invalid.

• # Process Changes – the number of changes made to the Discovery and Estimation process used in this iteration of the process based on results of a previous retrospective.

Lessons Learned

  1. Discussing and gaining support first across the organization makes the process more effective. Initially, this process was forced to break the cycle of “requirements delivery,” and over time, the results and team satisfaction with the process reduced the organizational resistance.
  2. Adapt the steps depending on the complexity of the work stream. Go shorter and omit steps if not needed.
  3. Generating actions items from the “parking lot list” prevents a loss of information and provides next steps. However, discipline is required to track their progress and discard action items that are not or no longer of value.
  4. The preparation for the process is key, both Ideation deliverables and the team should have some grounding in the work. Be careful of organizational pressure causing this preparation to be skipped or rushed.
  5. Create a space for team only time to digest information, discuss, innovate and prepare for the next session.
  6. Allocate the time for process improvement to occur in a timely manner to be prepared for the next iteration of Discovery and Estimation.

Generating shared understanding has proven to reduce surprises and increase team happiness. We have also found the projections to be accurate enough to force more conversations about the expected release content and the necessary follow-up planning. Are you satisfied with your Agile release planning? If not and you want to discuss release planning preparation in more detail, please contact victorjbartash@gmail.com or at https://www.linkedin.com/in/vicbartash/


[COHN-1] Cohn, M. (2006) Agile Estimating and Planning. Prentice-Hall
[COHN-2] Cohn, M. (2015). https://www.mountaingoatsoftware.com/blog/not-everything-needs-to-be-a-user-story-using-fdd-features

[COHN-3] Cohn, M. (2004). User Stories Applied For Agile Software Development. Addison- Wesley.

[GALEN] Galen, R. (2013). Scrum Product Ownership Balancing Value from the Inside Out. RGCG, LLC.

[PATTON] Patton, J. (2014). User Story Mapping Discover the Whole Story Build the Right Product. O’Reilly Media.

[SPACING] - https://www.anewspring.com/retention-training-the-spacing-effect-2/

[WATTS] Watts, Geoff (2013). Scrum Mastery from Good To Great Servant Leadership. Inspect and Adapt Ltd.

release planning ,collaboration ,emergent design ,agile ,process planning

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}