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.
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 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).
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.
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.
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:
The next table shows the salient features of story points compared to the other measure of effort, in-person days.
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:
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.
The following are some tips for better agile estimation:
The game of planning poker has its own advantages and challenges, as shown in this table.
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.”
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.
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.