Lesson 3 of 5
Planning and running sprints
8 min
A sprint is a fixed timebox, typically two to four weeks in SAP Activate Realize, in which a team builds, tests and demonstrates a slice of the backlog. The scope of a sprint is fixed once it starts. New ideas go to the product backlog, not into the running sprint. That discipline is what makes sprint results comparable and plans believable.
- Program alignmentProduct owners and teams agree the program-level sprint goal and cross-team dependencies
- Sprint planningTeam commits to Ready stories and breaks them into tasks
- Daily stand-upProgress and impediments; blockers escalated by the Scrum master
- Build and testConfiguration, development and testing inside the sprint
- Sprint reviewShow-and-tell to the business; feedback becomes backlog items
- RetrospectiveKeep, stop, start: improve how the team works
Sprint planning
SAP's agile Activate content gives practical rules. Estimate tasks in ideal hours, with no more than about four hours per task, so progress is visible daily. Plan only 50 to 70 percent of the team's available hours, because meetings, support and surprises take the rest. Check real availability instead of assuming everyone is full time. In scaled programs, align team sprint goals with the program sprint goal before planning.
- Day 1Sprint planningTeam Order to Cash commits to three fleet billing stories and one output story
- Days 2 to 12Build, unit and string testConfiguration in the development system; tests recorded and linked in Cloud ALM
- Day 13Product owner walkthroughMaria checks each story against its acceptance criteria
- Day 14Review in the morningShow-and-tell to key users; feedback captured as backlog items
- Day 15RetrospectiveTeam agrees one change, such as earlier test data requests
Running the sprint
- Daily stand-up: fifteen minutes on progress and impediments. In scaled programs, cross-team dependencies often surface here first.
- Impediments: the Scrum master removes them or makes sure someone does, fast. A test system outage or a missing role is an impediment, not a footnote.
- Testing inside the sprint: unit and string tests run as configuration completes; story test cases are prepared and executed before the review.
- No mid-sprint scope changes: new requests go to the backlog through refinement or the review.
Review and retrospective
The sprint review, around four hours in SAP's guidance, shows what was delivered, identifies and prioritizes new requirements, and updates the backlog. It is a show-and-tell in the system, with business users at the keyboard where possible. The retrospective, one to three hours, looks at how the team worked; SAP's content suggests sorting ideas into keep, stop and start.
| Ceremony | Purpose | Typical length (SAP guidance) | Who attends |
|---|---|---|---|
| Sprint planning | Commit to Ready stories and plan tasks | Varies with sprint length | Product owner and team |
| Daily stand-up | Progress and impediments | About 15 minutes | Team and Scrum master |
| Sprint review | Show results, capture feedback, update backlog | About 4 hours | Team, product owner, key users |
| Retrospective | Improve the way of working | 1 to 3 hours | Team and Scrum master |
Velocity and burn-up
After a few sprints, a team's velocity (completed story points per sprint) becomes a planning input. SAP Cloud ALM provides a burn-up chart for user stories, showing completed work against total scope over time. A burn-up chart is more honest than a burn-down for SAP programs, because it shows scope growth separately from progress: if the scope line keeps rising, the team is not slow, the backlog is growing.
What would you do?
Halfway through a sprint, Dan asks Team Record to Report to add a new intercompany report for company code 1810 "because it is small". The team has capacity worries already. What should the Scrum master do?
- Realize sprints run two to four weeks with fixed scope; new items go to the backlog.
- Plan 50 to 70 percent of available hours, with tasks of about four ideal hours or less.
- Reviews are show-and-tell sessions that update the backlog; retrospectives improve the process.
- Use velocity and the Cloud ALM burn-up chart, counting only stories that are Done.
Check your understanding · not graded
Lesson check
1. How long are Realize sprints in SAP Activate typically?
2. What happens to a new request raised mid-sprint?
3. What share of available hours does SAP suggest planning in a sprint?
4. Why is a burn-up chart useful for SAP programs?