Cadence in Scrum
Scrum coaches say that a Scrum Team (often Scrum Developent Team is meant) should adhere to:
- predictable cadence
- delivering business value each Sprint
But at the same time Scrum emphasizes that completing all the PBIs planned for a Sprint can NOT be considered obligatory, it is just a forecast.
These two points contradict to each other to some extent. But the second point makes much more sence to me than the first one.
For example, a Scrum Team may fail to deliver any PBI at the end of a sprint, but the lessons learned during the sprint and the new knowledge obtained (e.g. the fact that their understanding of the technology used was not precise and the business goal should be achieved in a different way compared to how they thought before) also have value though not immediatelly usable or shippable.
Another example - when experiencing technical problems durng a Sprint, developers may tend to use quick-hacks thus sacrificing the product's quality for achieving the Sprint Goal.
So is it right to say that a Scrum Team should adhere to cadence? Isn't it a fallacy?
I'm not seeing a contradiction here.
First, Scrum requires a predictable cadence. The cadence of Scrum is the Sprint, which begins with Sprint Planning and ends with Sprint Review and Sprint Retrospective. The length of a Sprint is generally fixed. Although it is possible to change the length of the team's Sprints based on stakeholder feedback or retrospectives, it's not generally done. This fixed-length Sprint gives everyone involved confidence as to a minimum frequency of delivery of at least a potentially releasable product as well as opportunities for synchronization and replanning.
There are a few key words there: "minimum frequency of delivery", "at least a potentially releasable product", and "opportunities for synchronization and replanning".
The Sprint does not have to be the frequency of deployment. The November 2020 revision to the Scrum Guide makes this clear: "The Sprint Review should never be considered a gate to releasing value." This opens up the possibility for Continuous Delivery and Continuous Deployment for the Scrum Team.
However, it is expected that at least one usable Increment is created during each Sprint. This usable Increment meets the team's Definition of Done and is suitable for deployment. Even if it's not deployed, the most recent Increment will be inspected as part of the Sprint Review to help stakeholders make informed decisions about the Product Backlog and future directions for the product.
Since the purpose of the Sprint cadence is not for delivery, it must be for something else. That something else is synchronization. The Sprint Review includes key stakeholders, who discuss things that have "changed in their environment" along with any "new opportunities" that have arisen. Previous versions of the Scrum Guide have given examples including talking about changes to the user base, market opportunities, schedules, budgets, and more. The effect of the Sprint Review is that the Scrum Team gains a deeper understanding of the current state of the world for the stakeholders while the stakeholders gain an understanding of the Scrum Team's context.
This describes Scrum's predictable cadence. However, Scrum also does allow for delivering value each Sprint, even though completing a body of work is not required. Scrum accomplishes this through the Sprint Goal.
As part of Sprint Planning, one element that is created is the Sprint Goal. The Sprint Goal is "the single objective for the Sprint". The expectation is that the Developers commit to achieving the Sprint Goal, but not to a particular body of work. By having a Sprint Goal, the Scrum Team can focus on the objective and self-organize toward it.
I've seen two common pitfalls with Sprint Goals.
The first pitfall is that the Sprint Goal is to complete a body of work. This minimizes the team's ability to figure out the best way to achieve the goal. With a good goal, the team may discover opportunities to achieve the goal with a fraction of the body of work that they expected. Goals of achieving a body of work tend to turn the team into a feature factory rather than a group of people who set out to solve the problems faced by stakeholders.
The second is that the Sprint Goal is too expansive. Achieving the Sprint Goal would require the full capacity of the team for the entire Sprint. It doesn't account for the fact that there may be unplanned work required to achieve the Sprint Goal, events may come up that reduce the capacity of the team, or there is urgent and unplanned work that is not related to the Sprint Goal.
I don't like the term "fail" with respect to either not achieving the goal or not completing any of the selected Product Backlog Items.
Sometimes, the team doesn't meet their goal. If this happens, that should be a key point at the Sprint Retrospective. The team should strive to figure out why they didn't achieve their goal. Maybe a lot of unplanned work came up, this work was extremely urgent, and the team didn't have enough time to work toward their goal. Maybe the goal was too big. Maybe the goal was too vague. Regardless of why the team didn't meet it, the Sprint Retrospective is the perfect opportunity for identifying and addressing the root causes for future Sprints.
Sometimes, the team may not deliver any of their planned Product Backlog Items. I don't think that this is a problem unless they also did not meet their goal. If they didn't meet their goal, use the Sprint Retrospective to figure out why. If they met their goal, then it's fine that they didn't complete any Product Backlog Items since they created value by meeting the Sprint Goal. The product that meets the Sprint Goal that is created at some point in the Sprint is potentially releasable and definitely inspectable at the Sprint Review.
Finally, the example of using "quick hacks" and sacrificing product quality needs to be addressed. This isn't consistent with Scrum nor the underlying principles of Agile Software Development. Scrum has the Definition of Done and the Increment must always conform to this. Neither the Definition of Done nor the general expectation of quality decreases. One of the twelve principles of Agile Software Development is that "continuous attention to technical excellence and good design enhances agility". Sacrificing the product quality may introduce a quick win, but will slow the team down in the long run, especially as more and more of these sacrifices are made.