Designing Sprint Cycle

In the figure, SAP Activate – Iterative Realize Phase, we can see how to apply the Sprint cycles to the Realize phase.

Note: There are different types of Sprint shown.

Sprint 0 is often needed for team and product initial setup activities that aren't producing new capabilities of a product that can be demonstrated at the end of the Sprint.

A firm-up Sprint is used for end-to-end testing and Product functionalities stabilization – scenario testing is performed and major issues are fixed. In this way, we ensure early discovery and fixing for the bugs and higher product quality.

In the SAP Activate methodology, the Realize phase ends with two special type Sprints: one for integration testing and another for final user acceptance testing.

In this section, we'll look closer at the following and see how these activities are modified by the existence of multiple Scrum Teams that are working in parallel in a scaled environment:

1. Sprint Planning
2. Sprint Execution
3. Daily Team Meeting
4. Sprint Demo
5. Sprint Retrospective

The Product Owner and the Development Team need to be aligned on the goals and scope of a Sprint.

In this example, we see what needs to be done for each User Story, the dependencies, and the desired Ideal Hours to complete a User Story.

Note the different types of tasks involved in completing each User Story.

SAP Cloud ALM offers a Card View to manage in a Scrum Board manner the project tasks, the User Stories, and advanced filtering capabilities that support the Agile Sprint Backlog visualization.

In the figure, Project Reporting and Burn Up chart, we can see Agile reporting capabilities available in SAP Cloud ALM.

When working on a physical Scrum Board, you'll see that each task has a sticky note with no more than four hours ideal time assigned per task.

We also recommend that you use different color pens or cards for each type of task.

The figure, Sprint Planning Meeting Examples, shows a real example of a board used in Sprint Planning.

Estimated hours are created using Ideal Hours. We won't always have ideal conditions, therefore, to be realistic, we need to consider that the sum of estimated hours should be between 50% and 70% of the available hours when we start running the Sprints. When the Sprint velocity is known, we can plan differently, but this is a good starting point for realistic planning.

Don't guess resource availability for planned work. Look at the true availability of resources.

The figure, Check Resource Availability in Sprint, gives you a simple example of resource availability checking.

In a scaled environment, when multiple teams are aligning to the same objectives, we must make sure that the team goals are coherent and are supporting the program level objectives for each Sprint.

Dependencies that are arising from this cooperation between teams must be identified and treated as 'integration points' that may affect the achievement of the Sprint goal if not properly managed.

Risks related to dependencies should be identified during the Sprint Planning and managed using the resolve, own, accept, mitigate (ROAM) process for risk management mentioned in an earlier lesson.

Release planning aims to identify and manage the dependencies between the Scrum Teams at the beginning of the Sprint Cycle.

The planning is a continuous activity that must also occur after each Sprint so as to assess the feasibility of the Release plan with the actual Scrum Team capacity to deliver as per the plan.

Changes to the Release plan may need to be operated if one or more of the following reasons occur:

• New backlog items may be identified and prioritized against existing ones.

• Roadblocks can delay the realization of the backlog items and affect the initial schedule.

• Estimations can prove to be wrong, and so on.

Before every Sprint planning, in a scaled Agile environment, the Product Owners must:

• Reprioritize the Backlog items for their Scrum Teams.

• Review the actual remaining Backlog with the product ownership team and, if it's needed, raise the necessity of a Release replanning.

• Review the actual status of the dependency completion.

• Have a common definition at the program level for the targeted Sprint goals for the Scrum Teams.

Before every Sprint planning, in a scaled Agile environment, the Scrum Team must:

• Understand the integration risks and potential issues, and consider them when carving the Sprint Goal.

• Align the Sprint Goal at the Team level with the Sprint Goal at the program level.

The scope of each Sprint is fixed. Never add new backlog items in the Sprint Backlog in the middle of the Sprint. These items can be added to the Product Backlog as result of Backlog Refinement meetings or, at the end of the Sprint, as a result of the Sprint Review meeting.

The team need to be sure of the definition of Done and have acceptance criteria defined for each User Story.

The Scrum Board is in place.

There are four user stories that each have multiple tasks.

User stories 1, 2, and 3 have one or more tasks In progress or completed with additional tasks to be completed. These three user stories are, therefore, classified as Active.

No tasks for User Story 4 have been set in progress or completed, so this User Story remains in the Sprint Backlog.

All tasks associated with User Story 1 are seen as Completed. Therefore, the User Story moves from Active to Testing.

When working with User Story 3, some additional tasks were identified and are added (shown as orange cards above).

User Story 4 now has some task cards In Progress, so the User Story is now Active.

User Story 1 has some test defects. Bug fixing tasks have been created for the User Story, and the User Story returns to the Active status.

User Story 1 and User Story 2 have now been completed and are ready for test or retest. Both these user stories are now ready for testing or test progress.

User Story 1 has been retested without defects and moves to the Done status.

User Story 2 had associated defects so is now Active whilst processing the three defect resolution tasks.

User Stories 1, 2, and 3 have completed retesting after completing defect resolution tasks. The User Stories are now shown as Done.

User Story 4 had identified two defect resolution tasks. These tasks are in progress so the User Story is seen as Active.

In the picture, Sprint Backlog and Governance with SAP Cloud ALM, we see the analytics capabilities of SAP Cloud ALM that, among others, are making the work status during the project Sprints transparent.

The figure, 3. Daily Stand-up Meeting, provides a summary of the Daily Stand-up Meeting. Some examples of obstacles that might be raised in the daily stand-up meeting are as follows:

• My laptop broke, and I need a new one today.

• I still haven't gotten the software I ordered a month ago.

• I need help debugging a problem with xyz.

• I'm struggling to learn xyz and would like to pair with someone on it.

• I can't get the vendor's tech support group to call me back.

• Our new contractor can't start because no one is here to sign her contract.

• I can't get the x group to give me any time and I need to meet with them.

• The department VP has asked me to work on something else for a day or two.

In cases where the Scrum Master cannot remove these impediments directly (for example, usually the more technical issues), they still take responsibility for making sure someone on the team does quickly resolve the issue.

In a scaled environment, when multiple teams are working on the same Backlog, although the work allocation strategy aims to minimize the dependencies between the Scrum Teams, they can still manifest, during the Sprint cycle, as blockers. For example, one team is working on a technical object that's already in progress with another team or a prerequisite activity for one team is in the backlog of another team.

Such roadblocks are examples of impediments that can be raised during the daily stand-up.

In the Sprint Review, the focus is on what's been delivered during the Sprint, identification and prioritization of any new requirements, and an update or review of the Product Backlog.

The figure, 5. Sprint Retrospective Meeting (1–3 hours), is all about the Sprint Retrospective. The purpose is to continuously improve the Scrum process using lessons learned from the Sprint execution.

The figure, 5. Retrospective, shows some thoughts for structuring the meeting.

As part of the Sprint Retrospective, you may use sticky notes to capture items under the following three headings:

• Keep doing: What went well

• Stop doing: What we want to avoid or change

• Start doing: What we want to improve

And then use red dots to vote or identify a collective view of the most important ones to action.

There are no bad ideas, just a collective prioritization.

The Sprint Retrospective activity isn't impacted by the scaled environment in the sense that it keeps the same internal team brainstorming meeting to identify the means and actions so that this team will improve its output. Some of the issues that could be the subject of the discussions and that would need improvement could come from collaboration and dependencies occurring as a natural consequence of working with multiple Scrum Teams in parallel.