Sprint Cadence — To follow or Not to follow
Cadence is defined as a pulse or rhythmical flow. Sprint cadence can be defined as the pulse of sprint starts, sprint finishes and more importantly the sprint outcomes.
We faced the question of whether our scrum teams should follow the same Sprint cadence. We looked into its benefits and pitfalls.
Key parameters of Sprint Cadence
We defined Sprint cadence to include the following key parameters
- Start day of sprints
- Duration of sprints
- Definition of Done
- Predictability of Sprint outcomes
The first two are fairly obvious and the third and fourth are important points that we want to address. If the sprint deliverables don’t meet the definition of done and are not consumable, then sprint cadence does not help. Similarly, if there is no predictability to sprint outcomes, then Sprint cadence won’t help either. In the absence of all the four parameters, sprint cadence is similar to a ticking clock with no impact on anything else. If all four parameters are met, then sprint cadence can be beneficial as we will see in the subsequent sections.
Should teams follow the same sprint cadence?
Benefits
Microservices & Dependencies
Our software product is built as a set of microservices. Microservices come with the usual benefits of small, autonomous teams continuously and rapidly building new features and deploying them to production. They enable us to share common functionality and reduces feature duplication.
While all this is hugely beneficial, the microservices have dependencies between them. A dependent feature if not delivered as expected, can have a potentially cascading effect on other teams’ releases.
For Example
We observed that teams were in different phases of a sprint: E.g. Let us say that Team A is planning their sprint, while a dependent team B is in a QA phase and yet another Team C is in a production release phase. Teams used to start their sprints on different weeks, and the duration was 2 to 4 weeks. The discussions and commitments made when Team A was planning their sprint did not have a high confidence level.
Cadence can be compared to the synchronized activities of an NFL team in every play. The quarterback, the receiver and everyone in the team have to be in sync to make a successful pass. The passing of the ball can be an analogy to delivery of a dependency. When the ball/dependency is delivered successfully, the dependent person can efficiently execute their next steps.
Another real life example is a team boating race. When everyone is in the same cadence, the forward progress is fast and smooth.Otherwise, the paddles can get entangled due to different frequencies thereby slowing down the progression.
Sprint Planning Time
Priority attached to planning by Team A was high as they were planning their sprint. Given their visibility, team B and C gave their best attempt to address team A’s dependencies.
Subsequently, when it came to Team B & C’s sprint planning, there were some rearrangements in priorities due to new stories that came into their backlog, which led to changes in the previously assumed priorities of Team A’s dependencies. This had an impact on Team A’s sprint and could cascade to teams that are dependent on Team A. We can extrapolate this to see what the effect is when the number of teams and their dependencies increase.
When teams have their sprint planning sessions on the same cadence, then the focus given to planning dependencies increases.
Scrum-of-scrums
Scrum-of-scrum meetings are where the scrum masters of different teams interact twice a week on inter-team dependencies. Since the teams are on the same cadence, they are in various stages of feature development such as development, testing, pre-production and production etc around the same time. When the teams meet for the scrum-of-scrum meetings, it is more effective as they can discuss feedback from testing and get things fixed. If some teams were instead pushing to production and others were in development stages, the priorities that they give to inter-team dependencies can be lower.
Multiple Dependencies
Our application layers which are built on underlying capability microservices can have more than 1 dependency in a sprint. If the teams were not on the same cadence, the release management for the upstream project can take more time. They may need to wait for 1 service to deliver a functionality at some point, and then another one to test their integrations. When faced with issues in QA testing, the other teams may have moved onto a different sprint. With teams switching context it may take more time to fix bugs.
Continuous Improvement
Another question that came up for discussion was whether teams should have the flexibility to lengthen or shorten Sprint duration depending on the amount of work.
To measure improvement, there has to be a constant reference. To measure the speed of a car, the road should not move.
The person inside the vehicle cannot observe or measure the movement or speed. The person standing still can observe the speed.
Similarly to measure the team’s improvement in velocity, it helps if the sprint cadence is constant. We are not saying it cannot be done with variable cadence, but it becomes a more complex calculation, just as it would be to measure the velocity of the car if the road also moves, and even more in unpredictable fashion.
Analogy from Nature
The analogy is that the day, week, month, year etc. are all fixed durations. Cadences can’t be extended even if larger pieces of work are slated to be finished in a day as all activities are planned with a natural constraint.
Not being able to do it with the calendar isn’t reason enough. Our takeaway is that work can be planned based on the calendar’s fixed cadence, without being affected by the constraint. This helps us overcome challenges and plan with a fixed Sprint cadence as well.
Pitfalls or Concerns
Dependencies tend to not be in the same sprint
An analogy was drawn was based on how we integrate with external APIs. Companies do not integrate with external APIs in the same sprint. The answer was to follow the same principle and treat other teams within a company similar to external products.
This question raised by this line of thinking is whether we should take advantage of efficiencies that one can derive from being in the same company. What if one’s competitors are able to derive such efficiencies and are faster to market?
Hence, this argument has to be viewed alongside advantages of Sprint cadence discussed above so that a decision is made.
Scrum & Kanban teams
In an organization there can be different types of product work. Some may follow Scrum methodologies and some may follow the Kanban methodology. Due to the nature of the work stream that adopted the Kanban style, there may not be a specific release date.
Possible solution
Hence, introducing cadence buffer in dependencies between teams and planning them one Sprint ahead is a common way to solve this.
All teams planning at the same time leads to chaos
It was observed that planning one’s own backlog is an involved task. Adding dependencies in and out of a team into the same cycle, then the different planning sessions can be chaotic.
There is enough merit to this argument.
Possible solution
This can be alleviated by the Product Manager staying two Sprints ahead of the team. The product managers and the scrum masters can also discuss the upcoming sprint dependencies in their scrum of scrum meetings. When these are implemented well it’s observed that the backlog and dependencies are clear and precise. The planning meetings both within and across teams tend to be more organized and less chaotic.
Conclusions
In this blog we addressed the question of synchronizing Sprint cadence across teams and whether teams should adopt it. Following the same Sprint cadence benefits the teams in multiple ways. Even though there might be some challenges, we believe that they can be mitigated or controlled.
