Longer isn't necessarily better.

Longer isn’t necessarily better.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project. As a general rule, once a team or a team of teams has settled on a specific cadence they tend not to vary significantly. While In today’s business environment a plurality of teams and organizations use a two-week sprint cadence, there is often a lot of angst over the finding the exact number of weeks in a sprint any specific team.  Many organizations adopt a standard and take the discussion off the table. With any specified cadence duration, there are typically three complaints: too much overhead, not getting stories done and not being able to commit resources on full-time basis to the work. In almost every case the complaint is coupled with a request to lengthen the duration of the sprint and therefore to slow the cadence.

  1. The sprint structure requires too much overhead: Sprints begin with a planning event and typically complete with both a demonstration and retrospective. Short stand-up meetings occur daily. Some team participants view these events as overhead. Scrum practice and observation of teams strongly suggests that the effort for the Scrum events increase or decrease depending on the length of the sprint. Longer sprints tend to require more planning and lengthier demos and retrospectives.  As a rule I suggest two hours of planning per week and 30 minutes each for the demonstration and retrospective per week in a sprint. Stand-ups should be approximately 15 minutes per day. For example, I would expect to spend 3 hours 45 minutes (2 hours for planning, 30 minutes for demo, 30 minutes for the retrospective and 45 minutes for 3 stand-up meetings) on events in a one-week sprint and 8 hours (4 hours for planning, 1 hour for the demo, 1 hour for the retrospective and 2 hours for 8 stand-up meetings). I have noticed that the effort for sprint events that are more than three weeks long tend to take longer than one would expect (four weeks sometimes being more than twice what is expected). Realistically, sprint size should not significantly affect overhead until you get to sprints duration’s of four weeks or more therefore overhead is not an obstacle to shorter sprints. Remember that in earlier posts we have shown that shorter sprints deliver feedback and value sooner so therefore are preferred all things being equal.
  2. Our stories can’t be completed during the sprint. This is typically not a problem with the duration of sprint, but either an issue of how the stories are split or a process problem. One typical corollary to this complaint is that the team can’t break stories into thin enough slices to complete. Most of the time this is a training or coaching problem rather than a technical problem, however in highly regulated environments or systems that affect human life I have seen scenarios where stories tend to require longer sprints due to very specific variation and validation. One common cause of this problem is assigning and hard wiring roles (testers can only test for example), which can cause bottlenecks and constraints if there is any imbalance in capacity. This is illustrated by the Theory of Constraints (take a look at our Re-read Saturday entries about The Goal for more on the Theory of Constraints). Typically, longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance because more stories are started and are subject to bottlenecks and constraints.
  3. Our organization can’t commit full-time resources to a sprint. Part-time team members typically have to time slice, switching between projects and pieces of work leading to some loss of efficiency. This is a reflection too much work and not enough capacity causing delays, constraints and bottlenecks. Similar to issue 2 above, typically longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance for the same reasons as noted above.

Many problems with cadence are either a reflection of process problems that generate overhead or poorly split user stories. For example, teams that do not have a groomed backlog will need to spend more time planning. Some team members see planning as avoidable overhead (the just wing it mentality). Overly large teams tend to have long daily stand-up meetings, again typically seen as overhead. Stories that are not thinly sliced will take longer to complete and have higher propensity to get stuck giving the team a feeling that a longer sprint is better. In almost every case, thinly sliced stories and committing to less work tends to improve the flow of work so that the team can actually deliver more. The duration of the sprint and cadence are usually not the root cause of the team’s problems.