User stories and backlog

An approved requirement says what the business needs. It is usually too large to build in one go and too vague to estimate. User stories break it into sprint-sized pieces of configuration or development that a team can plan, build and finish. In SAP Cloud ALM the stories stay linked to their requirement, so progress on the build rolls up to the promise the business approved.

Requirement, user story, sub-task

SAP's implementation best practice guide defines the entities clearly. A requirement captures a high-level business need and comes with an optional approval process. A user story translates it into a specific function that can be delivered within a sprint, and it supports agile practices such as story points and burn-up charts. A sub-task is a granular piece of work under a story, such as "configure the output condition" or "write the unit test". One requirement can have many user stories.

Stories or project tasks?

Cloud ALM also has project tasks, and the two look similar. SAP's guide says they offer much the same functions but serve different purposes: tasks are for organizational or operational work, while user stories carry user-facing, configuration or development value. The practical difference is traceability. A user story can be assigned to a feature; a project task cannot. Choosing a task for build work quietly cuts it out of the requirement-to-feature chain.

Planning the backlog

Refinement happens after approval. The team creates the stories, fills in the mandatory details and estimates them. Each story can be given a priority, story points, a sprint (timebox) and a team. Contoso's realize phase runs in two-week sprints; Kenji's ABAP team and the functional teams pull stories into sprints in priority order, and Priya watches the sprint view to see which requirements will be ready for which test cycle.

SAP's status flow for the leading practice shows stories moving from Open to In Progress or In Review and then Done, while the parent requirement moves through planning and realization. Status lists change with Cloud ALM's frequent updates, so agree in the project which statuses Contoso uses and what each means. A story marked Done that nobody has tested is a common source of false confidence.

Stories without requirements

Sometimes a story appears with no parent: a developer finds a needed change, or a consultant adds work directly to a sprint. Cloud ALM allows it, and SAP describes a user-story-driven approach for some cloud products. In Contoso's requirement-driven project it is a warning sign. Either the story belongs to an existing requirement and should be linked, or it is new scope that needs approval. Unlinked stories are invisible in requirement coverage, so the test lead never plans tests for them.