Creating Product Backlog

The basis of any project involves requirements. Here we'll consider a company, which is transitioning to Agile, where Elaine works as a Scrum Master.

The main question is around the project requirements. From the individuals requesting project work to the individuals completing project work, the concern is that this is handled in the best way possible.

In Agile, this involves a Product Backlog. Elaine's goal is to help her team understand what a Product Backlog is and how it works.

An Agile backlog, commonly referred to as a Product Backlog, is the representation of work available for the team to take on next. This doesn't include the work on which the team is actively working. The work moves from the Product Backlog to the team's active work. The resulting active work status depends on the framework used to implement Agile.

The type of work in the Product Backlog could include project work items, bugs to be fixed, and technical tasks. Depending on the team's responsibilities, production support items could be included as well. These typically take the form of a User Story, which is a project work item defined in terms of desired functionality for a specific user to reap a defined benefit. The Product Backlog items could take a different form, but the goal is to be concise and distinct from other work items.

Once Elaine has defined an Agile backlog, the next question is who's responsible for it. Because it primarily consists of the work needed to complete the project, the Product Owner, who represents the source of project work, owns the Product Backlog. This is a crucial responsibility, because the Product Backlog isn’t a static list of requirements but a grouping of work items that’s flexible and can be changed. This can occur at any time, because the work in a Product Backlog is what is to be delivered next and not what is currently being completed. It must be consistently prioritized and maintained.

These are the next things that Elaine reviews with her team.

The Product Backlog is a dynamic/iterative list of prioritized requirements. Details – which increase the level of clarity – vary based on the priority level of requirements and how close they are to be selected in the next Sprints to be implemented.

Prioritization means that requirements are ranked by Order and Level of Complexity/Size. Items with higher priority need to be fine-grained first, which means such Backlog items need to fit into a Sprint and can be realized by one team. Items with lower priority are more coarse-grained and will be split in smaller, sprintable items later.

The example shows a Product Backlog that's maintained in an Excel file, is implemented by multiple Scrum teams, and has indications for its items about:

• The team responsible (for example, Sales 2, STO)
• Story Points estimated
• The ranking that each Backlog Item has in the Team Product Backlog
• The Sprint in which the Backlog Item is planned for implementation

Requirements are Backlog Items with different levels of complexity, clarity, and detail.

Project work items in Agile that represent real (that is, actionable) project work take the form of User Stories, which are project requirements broken down into a smaller, more manageable form.

They're clearly described in one short sentence (User Story format) and are written to express a desired functionality and its associated benefit from an end-user's perspective.

User Stories are a form of project requirements that detail the desired functionality for a specific user. They capture the value that the requirements attempt to deliver.

Agile projects propose an incremental and iterative approach. User Stories are an incremental approach in the sense that project requirements are broken down into aspects of functionality.

Agile is iterative in the sense that User Stories are completed with repeated cycles of development, testing, and reviewing known as Sprints.

User Stories are sourced by the stakeholders of the project. These are the people who have requested the project and will benefit from its success or suffer from its failure. They are representative of the end users who will use the functionality.

While many stakeholders are involved, the key stakeholder, known as the Product Owner, is responsible for the User Stories creation.

The Product Owner is accountable to the other stakeholders for the User Stories written and is responsible for reviewing them with the Development Team. The User Story purpose is simply to initiate conversation and collaboration.

User Stories contain just enough information to reach a common understanding. Once a common understanding is reached, the User Stories are discussed and further details are added so the implementation can be completed, with a just-in-time approach. This approach is extremely valuable because it elicits input from everyone involved in the process.

The first step in writing a User Story is to answer the question of who needs the functionality. This involves identifying the user or the role (called 'persona', Latin for 'character') that needs the functionality. It's important to be as specific as possible and to not use a generic user (for example, 'SAP user'). The reason for this is because the user is foundational to the User Story and influences the functionality.

For example, if the team is working on a website for a company to sell clothing, functionality for the customer might include security aspects to protect their private information. This part of the User Story is written, 'As a [role], ...'

The second step in writing a User Story is to answer the question of what functionality is needed. It's important to define the functionality or need. This is what's developed or created. From the clothing website example, functionality for a customer could include checking out as a guest. The functionality of the User Story is written, 'I want [what] ...'.

The third step is to ensure that a business value added is defined for the requirement, so as to weed out those requirements that have no clear benefit attached and also to set the scene for the acceptance of the user story. The benefit of the User Story is written, 'So that [benefit] ...'.

Project work in Agile takes the form of User Stories, which are project requirements broken down into smaller, more manageable forms.

They're high-level and brief, no more than a single sentence or two. Each User Story is written from the perspective of an end user to express desired functionality.

The basis of the User Story concept is directly related to the foundation of Agile.

Agile is founded on principles from the Agile Manifesto, which is a set of statements that describe the values of Agile. These include the following:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Each aspect of the Manifesto is valuable but in circumstances where there are limitations and they aren’t all obtainable, some aspects are valued over others. The first two principles include individuals and interactions, as well as working software. These relate to the definition of User Stories. The end-user perspective directly aligns with individuals and interactions, and the desired functionality is representative of working software. The remaining aspects that are valued include customer collaboration and responding to change, which are related to how user stories are created.

From a process modeling perspective, the decomposition of processes drives the identification of solution gaps. Functional gaps might occur on a process or process step level. From there, we conceptually jump into a visualization to drive the solution design. SAP Solution Manager and SAP Cloud ALM serve as a common repository.

An example of the structure Scenario → Process → Process step / Activity might be: Order to Cash → Sales Order Processing → Create Sales Order.

In the figure, Terminology Mapping SAP Activate – Focus Build, we can see the mapping between the concept in SAP Activate and Focused Build solution for SAP Solution Manager.

For more information on Focused Build and SAP Cloud ALM, we recommend you review the following material, which gives the more details of SAP Activate, Focused Build, and SAP Cloud ALM.

In the figure, Terminology Mapping SAP Activate – SAP Cloud ALM, we can see the concepts utilized by both SAP Activate and SAP Cloud ALM.

The figure, Example: Capture User Story shows a sample User Story layout that can be created as a document or card.

SAP project-specific fields can be identified here beside the standard User Story elements:

• Headline to quickly identify the requirement in the Product Backlog,

• Functional area and process flow.

This figure shows how to document a solution process in the Process Authoring application that's delivered with SAP Cloud ALM.

Very often a requirement is associated with an SAP process and takes the form of an Epic in SAP Cloud ALM as its implementation requires a lot of work and can't be finished in a single Sprint.

This figure shows the SAP Cloud ALM user interface to create a User Story. You can notice in the screen on the left that a User Story is connected to a Requirement/Epic and that requirement is associated to a process flow in the solution.

This figure shows the SAP Cloud ALM user interface to break down User Stories into subtasks. User Stories can be broken down into subtasks and used for tracking completeness.

This is an optional activity for the Scrum teams, and it's part of the team agreements with regard with ways of working.

In the product Backlog, we can also capture the nonfunctional requirements, because these will also need to be planned, realized, and tested.

This figure shows the SAP Cloud ALM user interface to manage functional and nonfunctional requirements.

Only functional requirements are supposed to be linked to a solution process or to a process step. Categorization of requirements is possible so that they're easy to be identified and managed.

A User Story should be assigned to a single Sprint.

Whenever the Development Team informs the Product Owner that the User Story is too big and can’t be built and tested in a single Sprint, this should be broken down into smaller User Stories that can be assigned to their respective Sprints.

Often team members don't see any options to split items. The figure, How to Split WRICEF Requirements into Sprintable Pieces, is a cheat sheet that provides good ideas on how to split Backlog Items in smaller pieces.

This cheat sheet will help to find the right direction to be able to split big requirements on the business scenario level into smaller requirements on the process step level.

The INVEST acronym helps us to keep in mind all the characteristic of a good User Story.

A User Story should be independent, negotiable in terms of functionalities that are covered by a Story, valuable, estimable, small enough to be finalized in a Sprint, and testable. Therefore, there's a need for splitting and making it smaller while also keeping in mind the other INVEST elements.

The image Splitting as well as the links below give us more guidance on how to reach a finer level of granularity for our User Stories.

http://agileforall.com/resources/how-to-split-a-user-story/

http://agileforall.com/wp-content/uploads/2009/10/Story-Splitting-Cheat-Sheet.pdf

Remember that Requirements are large User Stories, very often not possible to be delivered in a single Sprint. We can also call them Epics.

In an SAP implementation project, during the Explore phase, we collect User Stories. We do that process-by-process during Fit-to-Standard workshops.

The User Story Mapping is a technique that shows us the big picture of the User Stories, which are identified for a user journey that at SAP are called business processes and scenarios.

The Business Process Map is enriched with the User Stories identified for the processes in that map, providing, like in camera lenses, zoom-in and zoom-out capabilities for the solution implementation scope.

The User Story Mapping technique helps the Agile Team to prioritize User Stories, to identify the minimum viable product, and enables the Release and Sprint planning.

In the figure, Story Mapping Process, we can see the structure of the User Story Map. The columns reflect how product goals contribute to the delivery of the overall product goal.

The first row of features (A1, B1, D1) describes the baseline or necessary features of the respective product goal. Together, these features are a marketable feature set or the minimum viable product (MVP).

As we have more features added to develop each product goal, we add these to the respective columns. Looking at any one product column, we can see an increasing level of features in the product.

In each column, the features supporting the same product goal are ordered by category: The absolutely necessary, bare minimal features that allow the achievement of the goal are placed on top of the column, followed by features that are giving alternatives to the user, then flexibility, intelligence, performance, comfort, and luxury.

Following the User Story Map structure of the previous figure, we have the overall goal of a scenario and each product goal is a process within that scenario.

The baseline functionality forms the first row of features and is the 'walking skeleton' or the minimum viable product (MVP). The additional features represented by the remaining user stories lead to a fully featured scenario and set of processes.

This process flow diagram shows processes A and B:

• Process A = Inbound Email

• Process B = Sales Inbound Call

This process flow diagram shows processes C and D:

• Process C = Marketing Inbound Call

• Process D = Marketing Outbound Call

In the figure, Story Mapping for SAP, in the top-left corner we can see the overall goal. We also see the four processes covered on the last two figures:

• Process A = Inbound Email

• Process B = Sales Inbound Call

• Process C = Marketing Inbound Call

• Process D = Marketing Outbound Call

We'll then look at process B (highlighted).

The top (purple) row now shows the Steps of Process B (Sales Inbound Call).

The rest of the story map shows a numbered feature of each step. In this example, there are no additional features required for the second and third steps to make the next feature level beyond the first feature set (row).

In the figure, Diving into the Service Inbound Call Process, the names of some of the features on the second row help you understand the approach and read the feature sets in the walking skeleton (or minimum viable product). Additional feature sets are shown below as other rows.

SAP Cloud ALM is where the User Story Map can be stored.

Please keep in mind that the User Story Map is a living artifact, as new User Stories (product features) can be identified and all remaining, not implemented User Stories in the Backlog have to be reviewed for prioritization and ranking purposes.

Where SAP Cloud ALM has been chosen, we can use entries in the Requirement to automatically sequence the requirements by Priority. User Story points and Effort information can be also stored in the tool.

If SAP Focused Build or SAP Cloud ALM are not being used, use the Priority Category and Priority Rank columns in the Project Backlog spreadsheet to prioritize and sequence the requirements.

In the figure, Ways to Establish Priorities, we learn the core prioritization techniques.

Other approaches include MoSCoW, where we assign one of the following properties to a User Story:

• Must have (defines the minimum set of features of the walking skeleton)

• Should have (high priority)

• Could have (Desired but not necessary)

• Would have (can be delayed for future release)

Then rank all the user stories within a priority.

We can then sequence the stories by priority and rank within the priority to get a sequence where no two stories have equal priority.

User Stories and Epics can be depicted depending on their risk level and value proposition.

Start with high risk and high value Epics in order to deliver value as early as possible and address risks and uncertainty.

Continue with Epics which have high value, but lower risk.

Do Epics with little value and little risk last.

If possible, avoid Epics that have high risks but offer little value/

Some User Stories might be valuable, not directly for the end-user, but for the company developing the product to eliminate the incertitude about the value of certain product features.

In this case, the most basic functionality (the MVP) of that feature is getting a 'discovery high business value' in the sense that, once live, that MVP gives the desired information about its usefulness and value in front of the end-users. This is preventing investments in low value functionalities.

In some other situations, the team doesn't know how the functionality can be implemented, so there's a discovery value in first elaborating a proof of concept or a study that will bring additional information on the how.

In Agile, this uncertainty is addressed simultaneously by assessing the discovery value as a component of the business value for each Backlog Item.

The above visualization showcases the importance of transparency and communication, specifically in large Agile projects.

The main goal during the Explore phase is to have a common understanding on the requirements and Backlog across the teams/workstreams.

The overall Backlog is the single source of truth for the project.

It is essential to build an overall Product Backlog right from the beginning as soon as the first fit-to-standard workshops have been started and first requirements have been captured.

The refinement on the overall Backlog is the responsibility of the Chief Product Owner together with the respective Product Owners.

In order to get a requirement into the next level, it's recommended to exchange and be aligned on the following items – this also helps to come up with a good ranked Initial Product Backlog at the end of the Explore Phase:

• Dependencies

• Assumptions

• Out-of-Scope aspects

• Risks (focus on business and market-view)

• Aspirations

• General requirements and remarks

• Negotiated agreement between parties

• Constraints (effectiveness/efficiency requirements)

• Artifacts and delivery-formats

• Exit criteria (for example, sunk cost; opportunity deadline)

Preallocation of the Backlog Items to the Scrum Teams can be done by a Core Team that is focusing on planning activities BUT the finalization of the Release Planning is done by the Scrum Teams.

Prioritization is done using the same priority value set (for example, MoSCoW) for all the Scrum Teams and the same priority ranks within the priorities.

Cross Workstream Collaboration:

• During the Explore phase, start working in a scaled Agile environment.

• Reinforce Agile structures across workstreams.

• The goal is to have a prioritized overall Project Backlog aligned across the workstreams.

• Focus on visualizing an end-to-end value chain driven flow and prioritize the backlog accordingly.

• Regularly refine and align as follows:

  • On cross dependencies across workstreams and requirements

  • On risks (pain points)

  • Reserve enough time and establish a Risk Roaming meeting

Dependencies are an important aspect to manage when working with multiple teams to develop or implement the same Product Backlog. Work to be done by a Scrum Team depends on a work to be finished by another team. During the Release Planning, all the teams are identifying dependencies and are sequencing the work so that blockers and bottlenecks are prevented. Nevertheless, the workload estimates are simple predictions that might be invalidated by the reality of the Realization phase.

Dependencies are one of the main sources for the project risks, but we can foresee technology risks, market risks, operational risks and many others.

When planning the release, we must identify the risks that could occur and decide the team's response to these risks.

The ROAM model breaks down the risk into four categories, Resolved, Owned, Accepted, and Mitigated, and allows teams to decide on what risks are worth working on, and who is focused on dealing with these risks.