Critical Checkpoints in Scrum – Part 1 – Release Planning

Two months ago, I was doing an agile practices review for one of our clients and I was surprised to see that despite his willingness to practice Scrum there was little understanding of it.

Even if most people I’ve met in the agile community have at least experienced the Scrum certified course, during debates I can see a major gap between how they perceive it and what Scrum really is.

It is useless to regurgitate that a lack of comprehension might do more harm to the organization than before the ScrumBut, as described in my previous article, Scrum requires a different mindset.

Suddenly all the important stuff we’ve been used to from the beginning of time’s disappeared and a strange mixture between the defined process control model (old approach) and the empirical process (the new approach) has to begin.

The Scrum Master ensures the 3 principles of an empirical process control are correctly applied through the main flow: transparency, inspection and adaptation. 

Transparency is one of the 5 great values of Scrum: commitment, openness, focus, respect and courage. Everyone should know how the team is organized, why they increment as they want and what the final results are. During the Sprint review the increment is inspected, so we can adapt the process through the Definition of Done (DoD).

The DoD is the mutual agreement between the Scrum Team members regarding the way work will be accomplished and acts as a guide during the planning sprint meeting while deconstructing work into tasks. As the DoD should help Developers understand what to do to maximize the value of a product and ensure the Product Owner’s satisfaction, the Definition of Ready (DoR) should help the Product Owner better prepare the Product Backlog Items (PBIs) for the Developers.

Generic DoD or DoR are difficult and sometimes even impossible to build because they are strictly correlated to the project context, hence the idea to publish what I consider critical checkpoints in Scrum.

Here is what I achieved after struggling several hours in order to structure the most important ready and done control points grouped by 4 of the major moments of Scrum:

Do you need further guidance on Agile – Scrum best practices? Contact our experts, they will be happy to provide coaching and advice adapted to your business expertise.

Release Planning

Rather a process than a meeting, Release Planning is one of the least spread practices in the community. The Scrum Guide covers too little about it, maybe because the effort dedicated to this activity is focused before starting the first sprint of the project – before starting the incremental and iterative cycle of a Scrum process.

A common misconception in agile development is the belief that agile doesn’t allow planning. The Release Planning ensures visibility in the medium/long term while Sprint Planning focuses on the short term.

In order to start a project we need to ensure the following:

• Product vision
• Initial product backlog
• Sprint size
• Sprint context & vision for prepared Sprints
• Backlog ready
• Team velocity
• Team capacity
• Shared release plan
• Release burn-down

Product Vision

Its purpose is to bind stakeholder and customer needs with the team’s goals and it is one of the 3 major responsibilities of the Product Owner:

Here is the checklist of questions I’ve extracted from Why the Stakeholder should not be mistaken with the Product Owner

Product Roadmap

The Product Roadmap is the list of already identified major milestones, structured by releases and listing high level functionality or release themes, used as a project starting point and business communication tool.

You can establish when an already identified release should finish:

• By choosing some calendar events, or
• By business domain, groups or themes of Product Backlog Items (PBIs).

Initial Product Backlog

The Product Backlog is a prioritized unique list of PBIs – requirements which must be carried out. This list is shared with the entire Scrum Team and other involved members. The product backlog will live during the entire existence of the product, so at this stage we are speaking about the initial Product Backlog that will continually be adapted by the Product Owner through the process.

Sprint Size

Ken Schwaber started to describe the Sprint in the Scrum Guide as follows: “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint”.

Here, a minimum set of questions the Scrum Team should ask itself before defining the size of the Sprint:

• Involved members schedule (clients…)
• Tasks related to the Sprint DoD
• Team size
• Frequency of change requests and their size
• Release end date
• Team motivation
• The maturity of the architecture

Sprint Context

The context of a sprint may differ from one sprint to another. The elements that define the sprint context are: sprint size, number of team members, occasional events, business domain… The Sprint Context should be taken into account by the Scrum Team during the Release Planning. An optional step in preparing the sprints is to focus the team’s energy to a mutually agreed Sprint vision. This vision should describe the main functional or technical purpose of the Sprint (Examples: “account management” or “SSO integration”).

Backlog Ready

In order to start the project we need several PBIs that cover at least 2 or 3 sprints. These PBIs should be small enough, estimated and prioritized. The Sprints covered by the PBIs and for whom we defined the context are prepared for the Sprint Planning Meeting. We cannot plan the PBIs without having every PBI estimated. The estimation method in Scrum in not prescribed. However the most commonly used estimation method is the agile planning poker.

Team Velocity

Velocity is a measure of productivity in agile development. The velocity is calculated by counting the number of relative points allocated to completed PBIs, according to DoD, during a Sprint.

Velocity alone doesn’t represent the big picture of the team’s performance!

Velocity = the quantity of delivered products (work items) / specific volume of effort expended. Performance = value-add/costs.

Team Capacity

The Capacity of the team during a Sprint is the total number of relative points the team is able to complete during that Sprint. This is calculated based on the team’s history. The velocity should allow us to track down how many man days of effort are necessary to complete a relative point. As we might not have any history at the beginning of the project, in order to estimate the effort needed to complete a relative point we can use more traditional estimation methods.

Here are several examples:

• Slice 2-3 PBIs and estimate them in man days together with the team. Sum the number of relative points for the chosen PBIs and divide it by the achieved number of days in order to calculate how much a relative point is worth in man days.
• Ask each team member how they estimate 1 relative point in man days, decrease the gap between the max and the min by clarifying their questions and make the average.

After the value of 1 relative point has been estimated in man days, the Scrum Team should be able to apply the formulas from the image below in order to calculate their capacity for future sprints.

Accurately estimating the capacity of a team is essential for the success of an Agile project. If you need advice during release planning, contact our Agile experts.

Shared Release Plan

In order to build the Release Plan, the team needs to iterate each PBI from the prioritized and estimated backlog and insert them into sprints, while passing from a sprint to another whenever the sprint capacity, in number of relative points, is reached. As this seems to be an easy task to automate, the PO might need to check and choose for a Sprint the PBIs that are less prior but fit better because of the iteration’s calculated capacity limit.

Release Burn-Down Chart

The completion of the Release Plan should trigger the instantiation of the “Big Picture” indicator, as characterized in the Glossary article of Scrum Alliance: “In Scrum, the release burndown chart is a “big picture” view of a release’s progress. It shows how much work was left to do at the beginning of each sprint comprising a single release. The scope of this chart is a single release; however, a product burndown chart spans all releases.”

Read more about the importance of gathering reliable data to appreciate agile performance

Conclusion – Critical checkpoints in Scrum – Part 1 – Release Planning

The false assumption that Scrum equals to the “do whatever” organizational framework is far from the truth. We might even tell that Scrum imposes a significant number of acceptance criteria when passing from one major moment to another.

The committed members must add new validation criteria in order to align the process with its goals.

The Release Planning will continue through the grooming sessions of every sprint. If the first session is done well, it should not consume a lot of effort during the sprints:

The Release Planning is not the only critical activity at project launch, but its absence might dramatically impact the expected results, the moral of the committed people, and the confidence of the business stakeholders.

The purpose of this series of articles is not to drill down every mandatory artifact or activity, but mostly to consolidate a minimum set of checkpoints that will serve Scrum teams as checklist and build a shared vision over the musts of Scrum. Likewise, these articles should help the reader answer the following question: How big is the gap between your current organization and genuine Scrum? because “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”- Scrum Guide. How is your Release Planning process?

Here is a selection of articles you may also want to take a look at:

• Agile transformation: connecting the dots of a two-year transition to agile best practices
• Agile and Risk Management
• 5 signs that a Product Owner will have difficulties with their Agile project

If you want to learn more about the Pentalog Consulting offer, take a look at our range of consulting services or download our price catalog.