At one of the lowest levels of Scrum development, you have Sprints. If you are combining Scrum with Kanban or have another iterative and incremental development, then you are likely to have iterations. In either case, with a small team and one Sprint backlog, it is easy to manage the dependencies, have the needed integration and deliver. When you have multiple sprints (iterations) running in multiple teams, the complexity increases in managing dependencies and delivery.
In such case, synchronization of Sprints is a practice for Agile development at scale. In place of overlapping Sprints, it is advisable to have synchronized Sprints for good collaboration, develop a cadence and have dependency management. Now, what happens when one of the Sprints - synchronized with same length or nested with different length – gets cancelled?
Sprint getting cancelled is rare, but it might happen, e.g., when the goal of the Sprint is no longer relevant.
Say there are Sprints of different lengths with a cancelled Sprint for one of the teams. The situation looks like this as shown below (Figure - 1). I have 3 teams – Team 1, Team 2, and Team 3 - running Sprints. The Sprint lengths are different. For Team 2 and Team 3, it is nested inside the Sprint for Team 1. But, Sprint 1 for Team 2 has been cancelled for certain reason.
 |
| Figure - 1 |
Some suggest that add on the days leftover from the current Sprint to the next Sprint and start off, which is like the one shown below (Figure - 2). As shown below, Sprint 2 of Team 2 has been extended to start some days before. Note that I have shown first Sprint getting cancelled. It may be other Sprint in the development cycle.
 |
| Figure - 2 |
First, Sprint cancellation is not an easy thing to digest by the team members. Let the team find out what went wrong or if by external reasons, what could have been done better. That takes some time. Starting off immediately, does not help address this case. In fact, I would suggest to have a small retrospective of what went wrong and how it can be avoided.
Second, the changes that you have made to the codebase while running the Sprints have to be commented out or removed or placed into separate classes or packages, as they may not used now. The branches that been created to have the code checked in and tested have to be tagged as such. If they have merged to the main branch (if there are dependencies with other team), have also to be addressed. These take time.
Third, though I am saying that Sprints can be of different length in different teams, I am also suggesting for the same team keep the team length same. Going forward, for every Sprint, I would like to see improvement in terms of delivery, e.g., by checking on the velocity. This is not possible if we change the length for the same team.
Fourth, Sprint length should be kept at same length (at least for 1 or 2 quarters) because it helps in reaching a high productive state. If you keep on changing the lengths, it breaks the rhythm or cadence.
Fifth, think of distributed environment where Sprints are running. How can the next Sprint immediately start off, if the previous Sprint is cancelled? It is just not practical.
After the cancelled Sprint, start the next Sprint as depicted below (Figure - 3). Have the next Sprint as scheduled earlier, which you would have done in your release planning.
 |
| Figure - 3 |
You may also like:
- My Experience: PMI-ACP Exam
- PMI-ACP Prep: Scrum Sprint I/O (Inputs and Outputs)
- PMI-ACP Prep: Scrum and Kanban – Similarities and Differences
- 30 Free Questions with Answers on PMI-ACP Examination (Part - 1)
- 30 Free Questions with Answers on PMI-ACP Examination (Part - 2)
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.