Sprinting to Your Goals in Scrum

By Mark C. Layton

Sprints, and their built‐in inspect and adapt model, are an integral scrum feature. It is through the sprint process that you are able to achieve the three agile pillars of improvement — transparency, inspection, and adaptation.

By breaking down your project into tangible pieces and then using the empirical model of scrum to assess your progress, you are able to constantly pivot moving forward. This allows you the nimbleness and ease of adaptation so sorely missing in waterfall.

Each scrum team member has the same purpose in the sprints — maximizing effectiveness in delivering potentially shippable product.

Sprints defined

Sprints are the essence of scrum. They are a consistent timebox for product development by the development team. Each sprint includes the following:

  • Sprint planning, including goal setting

  • Daily scrums

  • Development time, including regular review by the product owner

  • Sprint review

  • Sprint retrospective

The consistent timebox of sprints allows the development team to establish a development rhythm. It also enables scrum teams to extrapolate into the future based on empirical data like velocity. As soon as one sprint is finished, another begins. A flow of consistent iterative feedback loops is created and thereby is an ideal environment for production and continuous improvement.

Imagine that you’re a runner. You are consistently training for the 100-yard dash and have become incredibly proficient at it, but all of a sudden your coach asks you to run a marathon. If you attempt the marathon at your 100-yard-dash pace, you won’t finish the marathon. You need to modify your training to adjust for a marathon pace, which will require coaching, schedule, and diet changes over time. All the muscle memory and the type of endurance that your body has developed will need to be “relearned” to run a ­different length of race.

Planning sprint length

Because sprint goals do not change during a sprint, the answer to the question, “How long should your sprint be?” depends on your project and how long your organization can go without making changes. That is the outer edge. You have no reason to discuss going beyond that in duration.

For example, if your organization struggles to go a week without needing changes, don’t even entertain the idea of a two-week sprint. You won’t be able to maintain the integrity of the stability of the sprint, and stability is a huge driver of performance in scrum. Instead, discuss how much shorter you can make the sprint.

Also, sprint lengths do not change after they begin and ideally do not change throughout a project, unless they are being made shorter. If a scrum team changes sprint length during a project, it comes at a significant cost: Their earlier velocity is no longer relevant. Performance is not a straight mathematical line that can be sliced, diced, and reassembled. Just because a scrum team doubles their sprint from one to two weeks does not mean that they will automatically accomplish double its historical two-week velocity.

So, why are shorter sprints better? Shorter sprints decrease the amount of time between feedback received from stakeholders, enabling scrum teams to inspect and adapt earlier and more often. Longer sprints have a diminishing return because less of a sense of urgency exists due to the multiple days still available to the team. Weekends and longer sprint meetings can also have a negative effect on efficiency.

The capacity of a development team during a one‐week sprint may be either higher or lower than half the historical two-week velocity. You don’t have any idea until you run a few sprints, and you don’t know for sure until you run a lot of sprints.

Whereas the cost of changing sprint lengths throughout a project is significant, the cost of changing a sprint goal during a sprint is probably worse. If a sprint goal becomes irrelevant (for example, because of changes of company direction or changes in the market) before the end of a sprint, a product owner may decide to cancel the sprint. But be aware that canceling wastes valuable development resources and is quite traumatic to the scrum team and the organization. Also, the shorter the feedback loop (that is, length of sprint), the less likely a product owner would need to cancel a sprint.

One of the things you know from science is that you can’t turn off your mind. It’s always working. So, if you can give your development team a small number of problems to solve, and have them know that they’ll face those problems tomorrow, they’ll think about them consciously at work. Whether they want to or not, they will also think about them unconsciously when they’re away from work. This is why the stability of sprints is so important.

After a sprint starts, the developers must have confidence that the scope is stable. Ever have an epiphany while brushing your teeth? This is the dynamic. But you need two elements — a limited number of problems and confidence that you’ll face those problems tomorrow. If every day a developer could be working on Project A or Project C or Project who-knows-what, this won’t happen. They will only mentally engage when they get to the office and discover what’s ahead of them in reality. One of the reasons that agile projects are so much more innovative is that we have this stability and thus so much more of the developer’s mind share.

The one-week sprint length is a nice rhythm. It gives the development team clear time off, avoids weekend “cheating” to get more work done than is within the team’s capacity, yet is long enough for real progress to be made every week. This shorter feedback cycle also allows scrum teams to inspect and adapt more frequently. For these reasons, scrum teams should always be looking for ways to responsibly shorten their sprint length.

The key is to run sprints that enable your development team to realistically create tangible, tested, and approved product every single sprint. After each sprint, you will have something real that can be shown to stakeholders.