SAP Project Release Planning with SAP Activate

Release planning with SAP Activate is a six-step process involving multiple stakeholders from business as well as client IT, apart from your own team and stakeholders from the implementation organization. The following figure shows the six steps, which will be explained further in this post.

During this process, the business owners, through the product owners, define the product backlog and prioritize the user stories based on its business value. However, the Scrum team must identify any other technical dependencies to complete the sprint. These dependencies, after discussions with the product owners, will also become part of the product backlog. After the team identifies the dependencies, they will estimate the work and complete the work. After completion of the work, the product owner, in partnership with the business owners, will review the work, provide feedback, and either approve or reject the sprint. The Scrum team, finally, will create the working software release.

Organizations and projects have their own cadence to plan for the product features and release them; from the SAP deployment perspective, we’ve seen releases after every sprint, especially in cloud deployments, as well as releases after a group of sprints—mostly in on-premise deployments—depending on the business value that the release is adding. At the beginning of this process, the team reviews the three release constraints—scope, budget, and dates—and updates them, if necessary. The team’s velocity, which is an estimated value for a new team and the historical value for an existing team, along with the product backlog and the detailed roadmap, serve as an input to the release planning.

The three constraints will dictate the release plan and will vary based on the team’s level of flexibility. In almost all cases, the initial release plan happens based on the fixed scope during the proposal phase, and the team comes up with the high-level dates and budget. In the explore phase of the project, after the delta design workshops, the product backlog is ready with prioritized user stories, and constraints are known. The team completes the release planning and creates a list of product backlog items, known as a sprint map (see the table below), that are tentatively mapped with appropriate detail, including estimates and prioritization.

At the end of each sprint, the release planning process repeats with greater details and fewer unknowns, as shown below.

Now, with some understanding of the release planning, let’s look at the six steps mentioned earlier.

Step 1: Define Product Backlog

In the explore phase of the project, the team will identify the required business capabilities in the solution; during delta design workshops, the team will also identify the need for any additional configuration, extension, or integration. All these requirements will go into the initial backlog through which they will make it to the final product backlog, as shown in the following figure.

Some of the key features of the product backlog are as follows:

• The product backlog is a live document and will continuously change during the process, which is one of the four values of the Agile Manifesto.
• The product backlog represents the requirements that should go into the solution.
• The product owner owns the backlog.
• The product owner, in consultation with business owners, assigns the business value for each user story.
• The product owner prioritizes the user stories.

Step 2: Prioritize Product Backlog

The product owner prioritizes the program-level product backlog based on the business value. There are several prioritization techniques, including the most common one—the MoSCoW method—where the requirements are categorized into the must-have, should-have, could-have, and won’t-have buckets. When you have all the requirements in different buckets, the product owner must rank them within the group (cautiously, so that no items have the same ranking).

Step 3: Analysis of Technical Dependencies

Now, you have all the business requirements identified and prioritized. From a business perspective, let’s say the business stakeholder assigned a higher value to the purchase order as compared to the purchase requisition. In another example of an approval workflow (e.g., purchase order approval), the team identifies the requirements for ABAP code and email notifications. In yet another example, the development team identifies the user stories for creating users and assigning roles based on the approved segregation of duties (SoD).

In the latter two examples, it’s clear that the development team must identify the technical dependencies to ensure that the user story is ready per the definition of ready; they can then estimate the user story and deliver per the definition of done. In the first example also, the team must clarify the dependency with the business owner.

It’s also important to understand the concept of technical debt. Technical debt is the implied cost of additional rework that the team must pay to choose the better or right solution instead of an easy “Band-Aid” solution. While completing the technical dependency analysis, the team must minimize the technical debt.

Step 4: Estimate Product Backlog

The Scrum team must provide the effort required to complete the user stories. Based on the team velocity, an input to the release planning process, the Scrum team will pick up the user stories that can be done within the sprint duration per the agreed-upon definition of done. Traditionally, you would estimate the effort of an activity in in-person days or hours, but in Scrum, you utilize story points—an abstract measure that determines the difficulty level of the Scrum, which relates to the risk, complexity, or simply effort—for effort estimation.

Story Points versus Hours

A story point is an abstract measure for estimating a user story. The Scrum team assigns the story point for each activity, and the summation of all the story points in a given sprint is the effort required to implement the sprint. The ratio between two story points is important rather than the actual numbers. For example, if the story point of activity A is five and that of activity B is 10, then activity B is twice as much of a story as compared to activity A. Assigning 500 and 1,000 for activity A and activity B, respectively, is absolutely fine. Another common approach for the story point estimation is the use of Fibonacci series, a sequence of numbers where each number is the sum of the two preceding numbers and can start with 0 or 1 (however, for estimation purposes, we start with 1).

Story points must include all the factors that affect effort:

• Volume of work: The volume of work to configure chart of accounts is much less than configuring the material requirements planning (MRP).
• Associated risk: Consider the associated risk while configuring a process where the business process owner has signed off on the requirements to that of a process where the clerk has provided the detailed requirements, but the business process owner is asking for many changes.
• Complexity of work: Configuring MRP is, of course, much more complex than configuring chart of accounts.

The next table shows the salient features of story points compared to the other measure of effort, in-person days.

Planning Poker

Let’s play some poker. The best part is, no one will lose and there is no winner. It’s a teamwork process where you build consensus and decide on the required effort to complete a user story. The figure below shows the process of planning poker:

1. Read the story: The product owner or the customer reads the user story for the estimation.
2. Team estimates: After initial discussion and clarification questions, each member privately selects a card representing that member’s estimate.
3. Reveal cards: All members (nonexperts) show their cards at the same time. Experts will show their cards after all the nonexpert members.
4. Team discuss: If estimates are the same, then it becomes the estimate of that user story. If not, a discussion takes place that focuses on outliers. The process is then repeated until a consensus is reached.

You can play the planning poker with or without an expert; an expert, however, may help you and other members of the team with real-life examples, scenarios, and challenges that will lead to the more accurate estimation. The team composition may vary, and you can have all the members either with the same background or from different backgrounds. The end objective is to build the consensus.

Agile Estimation Tip

The following are some tips for better agile estimation:

• Everyone participates in the estimation exercise.
• Everyone must be aware of the definition of done and the concept of velocity.
• During the estimation process, most of the communication is verbal.
• Experts from similar projects and functional areas will help improve the results.
• With multiple experts, the team must build the consensus.
• Ask clarifying questions, if needed.
• Use the same measure of estimation for the entire project.
• Build consensus for all user stories. If, for some reason, consensus isn’t built, then try breaking down the story into smaller tasks. If it still doesn’t work, then defer the estimate for the given story to a later time.
• Use a free “get out of poker room” card to take a break.

The game of planning poker has its own advantages and challenges, as shown in this table.

Step 5: What’s in the Release?

At this stage, you have the complete requirements documented in the product backlog, a list of user stories prioritized by the business value, and team velocity, which is an input to the process. However, the three constraints—date, budget, and scope—will dictate the user stories in the upcoming release.

The product owner will decide the content of the release; remember that Scrum is about a value-driven mind-set where date and budget are fixed (e.g., time-boxed sprint). One of the values of the Agile Manifesto is “responding to change over following a plan.”

Step 6: Complete Release Planning

This is the final step of the release planning. The table below shows the first release comprising two sprints similar to the ones shown at the beginning of this post.

In Scrum, you should always anticipate additional requirements during the sprint.

Conclusion

As we’ve recently explored, Scrum is a great tool for project management to utilize that is riddled with misconceptions. Once you’ve made the choice to utilize Scrum in an SAP Activate context, however, you’re just six steps away from getting started on your project. This post laid those steps out. Also explore five golden rules for implementing SAP S/4HANA with SAP Activate here.

Editor’s note: This post has been adapted from a section of the book SAP Activate Project Management Certification Guide: Certified Associate Exam by Aditya Lal.