Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Building and refining the backlog

8 min

The product backlog is the single ranked list of work the program will take on next. In SAP Activate it is built mainly in Explore, from Fit-to-Standard workshops, and refined continuously through Realize. The product owner owns it. A good backlog makes sprint planning boring in the best way: the top items are clear, sized and ready.

What goes into an SAP backlog

  • Delta requirements from Fit-to-Standard, each linked to a solution process.
  • Configuration needs and values confirmed in workshops.
  • Integration, data migration, output and report needs raised by the business or other workstreams.
  • Non-functional requirements such as performance, security and audit needs.
  • Technical tasks and, later, defects that need build work.

Epics, stories and sub-tasks

Epic or requirementToo big for one sprint; often tied to a business process, such as consolidated fleet billing
User storyA slice that can be built and tested in one sprint, written from a user's point of view
Sub-taskSpecific technical or configuration work inside the story, such as a billing type setting or a unit test
Backlog levels. In SAP Cloud ALM these map to requirements, user stories and sub-tasks.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-202

SAP's agile Activate content uses the familiar story format: As a specific role, I want something, so that a benefit follows. The role should be real, such as "billing clerk for sales area 1710 / 10 / 00", never "an SAP user". Stories should satisfy INVEST: independent, negotiable, valuable, estimable, small and testable. If a story cannot be built and tested in one sprint, split it.

Prioritizing

The product owner ranks the backlog by business value. SAP's content describes MoSCoW categories followed by a strict rank within each category, and two further lenses: tackle high-value, high-risk items early, and give extra priority to items that reduce uncertainty, even if their direct value is modest.

LaterLow value, low risk: schedule when capacity allows
AvoidLow value, high risk: challenge back to standard
Steady deliveryHigh value, low risk: fill sprints reliably
Do firstHigh value, high risk: tackle early while there is time to recover
A value and risk view of the backlog, following SAP's agile Activate guidance.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-202

Refinement and readiness

Refinement is the ongoing work of making top backlog items ready: clarifying, splitting, estimating and adding acceptance criteria. SAP's content stresses that items must reach Ready before a sprint starts, because preparing them inside the sprint destroys velocity. Contoso's definition of ready is short:

  1. Linked to a solution process and, where relevant, a parent requirement in Cloud ALM.
  2. Written as a user story with a specific role and benefit.
  3. Acceptance criteria agreed with the product owner.
  4. Estimated by the team and small enough for one sprint.
  5. Dependencies on data, integration or security known and either resolved or planned.
  1. New itemRaised from a workshop, review or change request
  2. RefinedClarified, split, criteria added
  3. EstimatedTeam sizes it in story points or effort
  4. ReadyMeets the definition of ready
  5. PlannedPulled into a sprint at sprint planning
How an item moves to Ready. Only Ready items enter sprint planning.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-202

In SAP Cloud ALM, requirements can be broken down into user stories, which support story point estimation, assignment to sprints through timeboxes and a burn-up chart. Without a project tool, SAP's content suggests priority category and rank columns in a spreadsheet; Contoso uses Cloud ALM so that stories stay linked to processes and tests.

What would you do?

Sprint planning for Contoso's Team Order to Cash starts tomorrow. The top five stories have no acceptance criteria and two depend on a pricing interface that is not designed. What should Maria, as product owner, do?

Key points
  • The product backlog is one ranked list owned by the product owner, built mainly in Explore.
  • Epics or requirements split into user stories that fit a sprint, then into sub-tasks.
  • Rank with MoSCoW plus a strict order; tackle high-value, high-risk items early.
  • Only items that meet the definition of ready, including acceptance criteria, enter a sprint.

Check your understanding · not graded

Lesson check

  1. 1. Who owns the product backlog?

  2. 2. What should happen to a story that cannot be built and tested in one sprint?

  3. 3. Which item is the best user story role?

  4. 4. Which belongs in Contoso's definition of ready?