Are Sprints still relevant?

Image courtesy of Pixabay (Creative Commons).

The following post was originally developed for the Uptake Engineering Blog.

When it was introduced years ago, Sprint (Scrum) methodology was envisioned as a more nimble alternative to slow, outdated software engineering practices (primarily Waterfall). Over the next years, its value was clearly proven and its adoption is now widespread.

Recently, however, I’ve found that many people are beginning to question whether Sprints — once the nimble, disruptive methodology designed to cut through Waterfall’s bureaucracy and waste — has itself become burdened with the same waste it was designed to combat.

Some of the most common reasons I’ve heard for abandoning or devaluing Sprints are:

  • Too many meetings. Between grooming/refinements, planning, reviews, etc., there is a perception that while moving to Sprints does add some value, it is not offset by the amount of additional time that the team has to spend stuck in meetings (and thus not actually executing).
  • Dividing work into iterations is unnecessary. Particularly for teams that don’t ship at the end of every Sprint, spending time dividing the work into iterations seems pointless.
  • Estimation takes too long. Similar to the criticism regarding how many meetings Sprint needs, there is a perception that time spent estimating work is wasted and could be better allocated to actually executing.
  • The process is too rigid. When running in Sprints, dealing with changes in prioritization and/or unexpected work (e.g. support) is perceived as being more difficult with Sprints, since the work being performed by the team is planned a week or two (at minimum) ahead of time.

For these and other reasons, I’ve seen teams abandon Sprint methodology, often to the (perceived) greener pastures of Kanban or Scrumban. Teams seem to feel that these methodologies offer some of the benefits of Sprints — emphasis on delivery, the classic To Do/Doing/Done board structure, etc. — without all of the overhead.

I think predicting the demise of Sprints is premature, however. In the course of the last six months or so, I’ve either personally led or witnessed others lead multiple teams (at multiple companies) through the process of moving back to Sprints after a period spent trying Kanban or Scrumban.

The results are striking — with literally zero exceptions (yet), my personal experience is that teams come out of the transition to Sprints with better morale and increased performance. The performance increases are often quantitatively dramatic. In one case, one Sprint team was able to generate approximately the amount of revenue that used to be generated by two teams of approximately the same size about a year earlier using a Kanban-based system. In another example, a team went from finishing 10–20 points per two weeks under Kanban to 40–60 in Sprints within just a few months.

More importantly, I’ve found in 1:1s and conversations with the teams that they seem more relaxed, happy, and satisfied after the change back to Sprints than they were under Kanban or Scrumban.

While there are undoubtedly still times to use a flow-based system such as Kanban, I believe that Sprint methodology still offers a few key benefits that lead directly to the above results.


First of all, committing to Sprints forces hard decisions regarding scope. In any given task in a software project, once it is begun there are inevitably countless questions and tradeoffs that are discovered that must be resolved:

  • “Should we add a date/time picker here, or just use a text field?”
  • “This area of code is very outdated — can we take some time to clean it up so that future maintenance of this code is easier?”
  • “We can implement this the quick and dirty way, or make it configurable and extensible for the future — which is best?”

When working without hard time constraints, the temptation of both developers and PMs can sometimes be to tend towards the Cadillac version of any given feature, despite the fact that all the user really needs is a Dodge Neon. When I worked primarily on Consulting teams, where cost is tightly monitored, these types of micro-increases in scope often would end up adding 10% to 30% to the cost to develop the project — which more or less eliminated the profit margin from the project entirely.

Taking the Sprint commitment seriously and forcing hard negotiations and tradeoffs (“Using a date/time picker would be a better user experience, but we can’t afford the extra time.”) is the most reliable way I’ve found to ensure that projects ship on time and on budget. When I’ve coached teams and PMs to focus on scope negotiation in order to reliably deliver the stories scoped for the Sprint, cost overruns started to decrease until the average project only would run a few percent over budget.

More importantly, I’ve found that while making constant sacrifices like this on scope often feels in the moment like it’s going to result in software that is of lower quality, the reality actually seldom bears this out. As one example, it’s always tempting when developing a feature to try to add configurability so that the feature can be expanded or reused in the future. However, even when very smart people try to guess how a product might expand and add configurability to support those eventual use cases, that configuration often ends up at best being unused and at worst being a hindrance. Some of the worst technical-debt quagmires I’ve run across in my years as a developer originated from an early attempt to inject unnecessary flexibility or configurability where it wasn’t really required.

It’s almost always best to build a system exactly to fit only what is absolutely required, and leave everything else for later (when it becomes itself required). Forcing hard conversations around scope by committing to Sprints is an important tool to help that reliably occur.


Focusing on delivery gives teams more satisfaction in their work. Let’s get the obvious out of the way: finishing something is better than not finishing something. In the heat of the moment, however, it’s easy to lose focus of delivery in favor of refactoring that one piece of code or adding that one extra bit of configurability.

Projects that drag on and finish slowly (or not at all) not only sap margins, they sap morale. Teams start to feel like their efforts are getting nowhere and that they aren’t adding any value. Delivering on time, conversely, makes teams feel valuable and productive — even in cases where the work is not inherently very interesting.

Additionally, Sprints allow smaller-scale deliveries, and thus more frequent positive reinforcement. Without Sprints, teams working on a six-month project may only really feel a sense of accomplishment at the end of the six months when the project ships — until that point things are likely to feel like a bit of a slog. Breaking down the project into Sprints, however, naturally provides the team with a defined point to reflect on their accomplishments every Sprint. While completion of an arbitrary milestone like a Sprint is less satisfying than completion of a real milestone like a feature, it is still a morale boost to a team to set a goal together and then reach it. In my experience, morale is more consistently high when teams feel a sense of ownership over getting each Sprint done, whereas teams without Sprints often have spikier morale, with highs around major project completions and lows in between.


Sprints give teams space. Many people are naturally focused on tasks — when they complete a story or task, their first (and often only) impulse is to pick up the next story or task immediately. They feel that moving quickly from one task to another will maximize their efficiency.

To an extent, this is accurate — moving quickly between tasks with little to no downtime between can increase throughput. I’ve found, however, that if that constant ‘go’ mode is maintained for too long, eventually people become stressed and unhappy. They may begin to complain that their code is riddled with technical debt and there’s never any time to clean it up. Or they may bemoan not being able to learn new technologies. Finally, they may not notice any external effects but may just gradually notice themselves becoming stressed and overwhelmed.

To combat this, many people have gravitated to the idea of ‘slack’ (popularized by Tom DeMarco’s book on the subject, Slack). The general idea is that, in order to do their best work, organizations need to build in time specifically and consciously to think, innovate and reflect.

Sprints provide this structure on a team level naturally. If team members finish a task within a Sprint, they should attempt to pick up another task or help another team member with their task. If they aren’t able to do this, the first choice should always be pulling another task into the Sprint, provided that it can confidently be finished within the Sprint. If team members can’t confidently pull in a task and finish it by the end of the Sprint, this is slack time — take the remaining time and clean up some technical debt, learn a new technology, or prepare for some upcoming work. Often, when encouraged, developers can find ideas for products or improvements that will make the entire company better — they just need encouragement to use ‘slack’ time to think the solution through fully.

Furthermore, planning for slack time makes sense from a planning perspective as well. If you plan your work to consume all available time right up until the last minute of the Sprint, if any little thing goes wrong you immediately risk not finishing everything in the Sprint. If you plan to finish your work slightly before the end of the Sprint, however, you are more confidently able to use slack time to absorb the unexpected stuff that always comes up from time to time (“I wasn’t able to get anything done yesterday because I couldn’t get Docker to start locally after upgrading.”), preventing the team from either missing their commitment or scrambling to meet the commitment (adding stress and possibly sacrificing quality as well).


Tracking success is much easier with Sprints. When Sprinting, it all comes down to whether or not you hit your goal for the Sprint. This is advantageous from a quantitative point of view, as it enables all stakeholders to easily track in metric form the performance and output of the team.

More importantly, placing so much psychological emphasis on Sprint completion allows for very straightforward retrospection and improvement. Asking team members why they missed or hit a Sprint is a lot easier for them to assess than asking more arcane questions regarding cycle time or WIP limits — I find that when team members sit down and think about it, usually the issues preventing completion of a Sprint are fairly obvious. Easy and accurate identification of issues is one of the most important tools teams have to enable themselves to improve.

Tracking work in Sprints also makes it easy for stakeholders — the team itself, the manager overseeing the work, the PO planning the work, etc. — to accurately assess how the team is progressing both within the Sprint and within larger Epics or projects. Without Sprints, tracking work against a large, multiple-month project can be difficult and risky; with Sprints, as long as the total number of Sprints’ worth of work is known, if the team meets their goal each Sprint the project will confidently complete on time without having to keep the entire project in mind at all times.


While I agree with the assessment that Sprints aren’t for everyone, I still believe from my personal experience that (largely for the above reasons) Sprints are one of the most effective methodologies currently available to many teams. In particular, I find that, while Sprints do require more structure than some other methodologies, that teams that still progressing towards true high-performing status benefit from some of the good habits that adopting a stricter structure can confer.

Want to submit your story to Product Management Insider? Click here for details.