Teams that Finish Early Accelerate Faster


... the Development/Delivery Team may work together well but struggles every Sprint to attain the Sprint Goal. In the worst case the team is feeling demoralized, and velocity is low.

✥      ✥      ✥

Teams often take too much work into a Sprint and cannot finish it. Failure to attain the Sprint Goal prevents the team from improving.

Development/Delivery Teams can be optimistic about their ability to finish PBIs. But in doing so, they fail to give themselves time to reduce technical debt and sharpen their saws. Thus they are doomed to a persistently slow pace.

Market pressure and low velocity may make the Product Owner desperate and the Development/Delivery Team will accept larger and larger Sprint Goals. This compounds the problem and they decelerate.

Individuals on a team may be working on other things subversively. This gets hidden in the work of a team that persistently overreaches.

If the team takes on too much work, they feel overburdened and under pressure. When they cannot get the work done by the end of the Sprint, everyone is unhappy — the Development/Delivery Team, the ScrumMaster, the Product Owner, and management. Furthermore, they do not have time to think clearly about how to improve their work, and will probably enter the next Sprint with undone work.

A lack of basic understanding of lean practices is often a cause of management pressure on teams. Taiichi Ohno’s taxonomy of waste has the category of “Absurdity” — stress due to excessive scope. [1] This can cause massive slowdown.

Muri (無理) is a Japanese word meaning “unreasonableness; impossible; beyond one’s power; too difficult; by force; perforce; forcibly; compulsorily; excessiveness; immoderation,” and is a key concept in the Toyota Production System (TPS) as one of the three types of waste (muda, mura, muri) (see articles for respective terms in Wikipedia).

Therefore:

Take less work into a Sprint (than the previous Sprint) to aim for a less ambitious Sprint Goal.

Yesterday’s Weather will maximize your probability of success. Then implement Illegitimus Non Interruptus that will systematically deal with any interruptions prevent you from finishing early. On early completion of the Sprint Goal pull forward from the next Sprint’s backlog, which will increase Yesterday’s Weather for future Sprints. To increase the probability of acceleration, apply Scrumming the Scrum to identify your kaizen in the retrospective. Put the kaizen in the Sprint Backlog with acceptance tests (see Testable Improvements) for the next Sprint as top priority.

✥      ✥      ✥

Openview Venture Partners noticed this pattern after analyzing data from dozens of sprints with multiple teams. The teams that finished their Sprint early accelerated faster. [2] This was the root cause: finishing early. It allowed teams to think more clearly about what they were doing — remove impediment; pull forward backlog from the next Sprint; develop a winning attitude; and increase Yesterday’s Weather.

An earlier version of this pattern was published as [3].


[1] we need this reference

[2] J. Sutherland and I. Altman. “Take No Prisoners: How a Venture Capital Group Does Scrum,” in Agile 2009, Chicago, 2009.

[3] Jeff Sutherland, Neil Harrison and Joel Riddle. Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams. In 2014 47th Hawaii International Conference on System Sciences, pp. 4722-4728.


Picture from: Simon Williams, https://www.flickr.com/photos/simonw92/6916799749/, (under CC BY-ND 2.0 license).