Analyzing Release Planning

Understanding the difference brings us to the point that a Release in the traditional approach is fixed in terms of scope, and usually in time too, but could be shifted if necessary.

In the Agile approach, you fix the Release, but you're not fully sure yet about what will be released, as needs and complexity can change. Over time, the better teams can predict, the clearer your Release will be, but still it can change based on requirements.

The Value-Driven approach puts the focus on the Customer success.

The Plan-Driven approach puts the focus on the Project success.

Starting to plan a Release, several pieces of information are needed. The Sprint length has to be clear to schedule potential Releases.

Furthermore, the Initial Backlog has to be built up, on which the teams can then perform a first high level estimation and prediction to get a first view on what could be delivered in which time frame.

Therefore, the Scrum Team needs a first understanding of their velocity (speed). The Product Owner needs to decide what the minimal viable product is supposed to be in order to be released. At the beginning, this is all a bit vague and only estimated, but it will become more precise over time. Nevertheless, the expertise of the SAP consultants helps to have a good first estimation.

The Product Owner is the responsible and accountable person for the Backlog and, therefore, the person building up the Initial Backlog with the team.

The prioritization is done by the Product Owner and supported by the Development Team to be able to decide about release content.

A clear understanding of 'How to demo' is important as this will lead to clear acceptance criteria for each requirement and User Story needed to rate and justify if the delivery is as expected.

For SAP implementation projects, keep in mind that Requirements will be split into pure configuration items and WRICEF objects, which represent developments on the standard solution.

For Public Cloud solutions, the Product Backlog will include mostly configuration items, as WRICEF developments are specific to managed cloud an on-premise implementations.

Prioritization is key to telling the teams what they should focus on and also to decide what matters for the Release.

Based on business priorities and complexities, the Product Owner prioritizes the Backlog.

There are various methods to do that. The most simple one we use in SAP Activate is the Must-Have, Should-Have, Could-Have, Would-Have (MSCW) rule.

In this case, we're not yet talking about the single User Stories that are pulled by the team, but initially about the high-level requirements first that will be split into User Stories over time and prioritized again.

First, you rate the requirements with the MSCW rule. This will lead to multiple requirements with the same ranking. As no item is allowed to have the same priority, as you have to be able to choose in bottleneck situations, you're going to rerank within those groups as in the figure above.

This process must be done for all requirements in your Initial Backlog and it provides a very good understanding of what is needed and what isn’t.

Besides the flat backlog view, which is simply a list from top to bottom, remember the User Story Mapping. Visualizing your requirements from an end-to-end perspective, starting from your Business Process Maps, will simplify your decision about priorities. The Story Map may not only be used to define what goes into which Sprint but can also be used to visualize the priorities, which will then be transferred into the Product Backlog. This way your Story Map will drive your Release planning.

When it comes to Product Backlog creation and prioritization, you need to be aware that besides the business requirements, IT does have some needs in order to be able to deliver the business needs.

Those are usually technical enablers and can be cross-functional requirements. Therefore, the Product Owner needs to work closely together with the Development Team to understand those prerequisites, which will lead to possible priority changes.

Finally, dependencies of any kind (business, technical) are to be considered too. An item might be of top priority, delivering a lot of value, but can only be implemented when other items (for example, Masterdata, APIs, and so on) are already implemented. There are not only dependencies within your project, which are easier to negotiate, but there will be dependencies to other teams and departments outside the project, who are following their own schedule.

Making dependencies transparent it will lead to a different prioritization.

If all information is gathered and understood, the teams have to start initially rating the complexity of each single requirement to provide a first indication for the release plan and required budget. There are two known approaches:

• The traditional – person days. The team usually has a good understanding and experience of how long single items will take. Nevertheless, this rating is a net rating. The teams have to consider that a typical developer/implementer can concentrate on the work for 4–6 hours. The rest is administration and backlog support for the Product Owner.

• The second approach – Story Points – is a relative rating based on complexity. By using story points, the teams aren't biased by days, but will rate their understanding of how complex the item might be. Over time, the team develops a good understanding of its velocity, telling the team how many story points they can deliver within a Sprint.

Each team does have its own complex understanding of its items and can’t be directly compared. But the trends and speed are quantifiable and comparable.

Those four questions will help the team to do their rating.

Estimation does include everything (for example, testing, documenting). Therefore, the team must understand the definitions of Done to count them in.

Planning Poker may be used to help show individual thinking on estimates and arrive at a consensus. The figure, Estimate Project Backlog: Estimation with Planning Poker, includes this summarized approach:

• Each estimator selects a set of cards (or you agree to use the Planning Poker app on your mobile phone).

• The Product Owner or customer reads the item to be estimated.

• The item is discussed.

• Each estimator privately selects a card representing their estimate. The card isn’t shown to other estimators.

• Once each estimator has selected a card, all cards are turned over at the same time.

• If everyone played the same card, this is the estimate.

• If estimates aren't the same, the group discusses the estimates, focusing on any outlying values.

• Repeat until estimates converge.

• The Scrum Master decides when to stop the reestimation rounds if the estimations aren't converging. Additional Backlog Refinement meetings need to be scheduled to clarify the requirements for which the estimations aren’t converging.

Straight Planning Poker is best done when team members have a similar background and understand each other. If this isn't the case, discussions might take longer to gain consensus, and good facilitation from a Coach or a Scrum Master is required.

When in situation 2, where those estimating have different backgrounds and cannot judge estimations of each other, we can adapt the Planning Poker approach as mentioned in the figure.

This little change ensures that team members aren’t influencing each other, trying to hide a lack of knowledge or following the experts or more extroverted members.

The figure, Estimate Project Backlog: How to use Planning Poker with a Twist? Steps 1 and 2, and the next figure show an example, in four stages, of Planning Poker where team members have different backgrounds.

The expert's estimate mustn't influence the initial estimate of the other team members and, therefore, doesn’t show their rating before the others do.

• Each estimator selects a set of cards.
• The Product Owner or customer reads the item to be estimated.
• The item is discussed.
• Each estimator privately selects a card representing their estimate. The card isn’t shown to other estimators.
• Once each estimator has selected a card, all cards are turned over at the same time except the expert's card. The expert waits to show his card until all other cards are turned over.
• If everyone played the same card, that's the estimate.
• If estimates aren't the same, the group discusses the estimates, focusing on any outlying values and understanding the reasoning behind each other's estimate. Then, the expert explains their estimate incorporating any insights gained from the previous discussion.
• Repeat until estimates converge.

Estimation isn't something easy, specifically when the team didn't yet work together and doesn't know the customer well yet. This figure does provide some tips and tricks for making the estimation easier.

This figure shows how the velocity of a team is calculated. Teams will be slower at the beginning, speeding up over time. The velocity is the average of story points delivered in the last Sprints. If the team estimated the first time, they'll have to create and use reference stories to gain a first understanding of complexity and, finally, of their potential velocity.

Finally, the requirements are in the Backlog, have been ranked and estimated, and can already be distributed over Sprints or Waves. With that, the Product Owner can define and estimate the deliveries for the first Release. Remember, priorities can change. Also, not all details are known yet but will be worked out during the refinement session.

As a result of the Product Backlog estimation, we'll have a prioritized, ranked, and estimated backlog that's ready for the first Release planning. We'll attempt to foresee, based on the information that we have, which User Story is possible to deliver in which Sprint and by which team, if we're in a scaled Agile environment.