How to achieve sprint-thinking in project management

Nov. 9, 2020 / By Steve Austin

To achieve great things, two things are needed: a plan and not quite enough time – Leonard Bernstein

One of the essential behaviors of high performing agile teams is framing their week-to-week work as sprints. In this context, the word sprint is not like a hundred-yard dash where team members sustain maximum effort for the entire week. Never-ending hundred-yard dashes aren’t sustainable long-term for people or for teams, and we don’t want to burn people out. Instead, a sprint defines a consistent period of time, usually a week but sometimes two, that always starts on the same day of the week. As mentioned in my previous blog, what defines a sprint are the agile “ceremonies” that occur within the sprint: backlog planning and refinement, daily stand ups, sprint reviews and retrospectives.

Because work sprints are predictable and recurring, they fit naturally into the cycles to which we are very attuned: the patterns of weeks, months, seasons and years. In my experience, teams and organizations adapt to sprint-thinking quickly and easily. Sprints are also numbered. Your first sprint is sprint 1, the following sprint is sprint 2, and so on. As I write this, the 3M 360 Encompass development teams are on sprint 271, reflecting the agile journey we started more than five years ago, at 52 sprints per year.

A sprint creates a consistent time-box to measure outcomes and effort. Consistency is key. The question “Are we performing better?” can only be answered when there is something comparable to measure against, and sprints provide this denominator. Another advantage of using the term “sprint” versus “a week” is that teams can elect to start their sprints on a different day of the week than the traditional Monday. At 3M, many teams start their sprints on a Tuesday so that three-day weekends won’t throw the weekly sprint cadence off. Larger efforts can then start to be estimated and planned in terms of the number of sprints needed. 

Sprints allow teams to set their goals ahead of time, and measure their progress every day so they know how they’re doing (if they start to fall behind, this may indeed necessitate some real sprinting to catch up!). Most importantly, by measuring their progress against sprint goals, they are able to adjust and adapt if necessary. Sometimes it’s not always about catching up; just as often, teams find they can pull in additional work during their sprint and do more than what they originally planned. When teams start measuring their velocity, the rate at which they are completing work, those measurements are per-sprint.

Sprints create a natural finish line for work. How do you know when you are done? Or, even more importantly, how do you know if you’re going to meet your goals? By knowing in advance how much work will be done at the start of the sprint and by tracking work as it is getting done (and having the ability to “radiate” that progress automatically), teams know how they are doing, managers know how their teams are doing and there’s less need for ad-hoc communication, status update emails or phone calls.

A successful sprint is one in which all of the work that was committed to was completed by the end of the sprint, meeting all acceptance criteria for being completely done. Teams will typically challenge themselves to improve some aspect of their work so they can do more of it in subsequent sprints. High performing teams show a steady increase in their velocity, meaning that they are able to do more now than they could before as the result of the improvements they make in their processes. 

An unsuccessful sprint is one in which the planned work for the sprint doesn’t get done. Any number of factors can cause this, but usually unplanned events or additional work or a change in priorities are usually the main culprits. Importantly, partially completed work for a sprint doesn’t get counted as done work for the sprint. Therefore, there’s a premium placed on completed work (in the software world known as “shippable software“). Larger projects will definitely span multiple sprints, but the backlog for a larger project should be decomposed as far as possible into sprint-sized chunks. In sprint-thinking, unsuccessful sprints are learning opportunities, and teams will discuss any issues openly and candidly during their sprint retrospective.

In the real world, priorities change in every organization frequently. Sprint-thinking allows organizations to remain flexible and adaptive while still delivering a predictable level of output and measuring and demonstrating progress.

Steve Austin is innovation manager for the 3M 360 Encompass System.

Discover how to streamline the revenue cycle, automate coding and reduce burdens on clinical staff.