Cadence in Scrum

Question

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?

Answer 1

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.

Answer 2

Through its events (the sprint itself, planning, daily, review, and retrospective), Scrum does indeed provide a cadence for the team to do the work. It is a rhythm that the team uses to do the work. Within this rhythm, the team will develop a velocity. You can then use velocity to make predictions about future progress.

Don't confuse the cadence with the actual PBIs that the team delivers in each sprint. To use an analogy, the cadence is like a CPU clock. The team then figures out how many "instructions" they can perform with each tick of the clock, so to speak. The idea is to go at a sustainable pace, that means do do just the right amount of work each sprint. If they go too slow, then the team is wasting company resources. If they go too fast, they will create hacks or take shortcuts to finish all the PBIs in the sprint.

Work can be done earlier, on time, or can be late. A team that eventually finds its rythm will smooth out these cases and stabilize around some velocity that then offers predictibility when laying it over a known sprint cadence and you can, for example, forecast some releases with some degree of confidence.

If there are unknowns, or exploratory work is needed to discover or learn things, you can use spikes within the sprints. Overall velocity will of course decrease, as each sprint some time goes to this work instead of on delivering PBIs, but the team will again find its rhythm within each sprint. The cadence is there so that the team finds a sustainable rhythm that can allow them to keep the pace indefinitely (basically, same effort each sprint - as opposed to, for example, more traditional projects where the pace is chill in the first phases of the project like requirements and design, then everyone stressfuly rushes at the end of implementation, testing and deployment to get the thing out the door).

There are Agile practices - like Kanban forexample - that don't have a cadence, but even there people will usually create some, like daily meetings, or scheduled retrospectives, or regular points for gathering feedback.

Answer 3

That you have a "predictable cadence" did not mean you have a predictable output of PBIs. The cadence is the time framework, tells you when you will do which scrum events. Starting from the dailies up to the retrospective.

It may happen that you will not achieve (some) of your sprint goals but it should not happen permanently. If you permanently fail to deliver, you have a more general problem. Maybe the tasks are not fully understood, maybe the stories were not exact enough ( definition of ready ) or your team knowledge is to low.

If you see this as a persisting problem, try to shrink stories, create "investigating stories" which will not deliver anything you can ship but increase team knowledge. You may think to build prototypes only for your team knowledge or even to see if your stakeholders are happy with your "idea" of implementation before you start to implement bullet proofed code/products.

"obligatory" in the sense of "must deliver" can never be a good idea. If you will guarantee to deliver, you have a perfect knowledge of what you want to do and have exact NO risk or you plan the time to solve all risks which may happen. If you do the last, you will waste all the time, if the risk will not take place which is not productive at all.

To make a better planning, the refinement is the most important part of your ( daily ) work! You should spent enough time to reduce uncertainty upfront you really start implementation. But this work is work and should be planned as stories as all other work in your sprint even if it will not generate any "potentionally shippable delivery".

Answer 4

"I see it a lot, but ..." A team should not "embark upon a sprint" as a way of learning how the technology works or how the goal should be achieved. Unfortunately the methodology is fairly silent on how you should account for this very-important task. As the Perl folks like to say, "There's More Than One Way To Do It,™" and it's really important to figure out what the best way is before you start to "seriously try to implement" anything.

If you like, you can make a "sprint" that consists of investigation and evaluation. No, that sprint will not, itself, "produce any 'thing,'" but it's vital to pave the way for later sprints that will. What you very definitely don't want to do is to stumble-around with the first idea that pops into someone's head, just to give the (mistaken ...) impression that "you are doing something." If you don't know yet what you're doing, you're not doing anything. If you're figuring out the best way to proceed, you're not doing anything yet.

A "cadence" is not "a rigorous schedule which must be adhered to for religious reasons." It comes from a cycle of carefully planning the work, parsing out an appropriate piece of it, completing it to a degree of acceptable quality, and being able to do all of that consistently.