To Sprint, or Not To Sprint

How to decide whether and which sprint processes are right for you

If there are two universal truths of process maturity, they are that new companies never start out with sprints, and that almost everyone ends up there eventually.

A corollary is that each team must decide if and when to start doing sprints.

Spoiler alert: like leaving a bad job, almost everyone waits too long.

I’ve worked with multiple teams in just the past week who waited too long to adopt sprints and needlessly suffered.

As with most issues, people hate change and tend to avoid it until things get so bad that there’s no other option.

With software planning, “so bad” looks like:

• Completely unreliable project estimates, often taking 2-5x as long as originally planned.

• Stakeholders have no idea when specific tasks will be done, with small tickets often taking weeks.

• So, stakeholders start following up daily with engineers when something is important.

• Engineers end up having to juggle several tasks and act as mini project managers, deciding which stakeholder request is most important.

At the same time, newly formed close-knit teams usually do just fine without sprints, and some mature teams operate successfully without them too.

How do you know if you need sprints, and when the right time is to adopt different sprint practices to avoid things getting bad? This article provides the answers.

What is a sprint process anyway?

Before getting into the signs that you might want a sprint process, it’s important to define what that is.

If you do things strictly by the book of scrum and agile, this means a lot of things, including:

• Fixed-length planning increments (e.g., 2 weeks)

• Daily stand-ups

• Sprint planning / backlog refinement meeting

• Sprint review meeting

• Sprint retrospective meeting

• Story point estimates

• Sprint goals

• Avoid adding new work to the sprint after it starts

• Clearly defined scrum master and product owner roles

If you actually do all of these things, and you have a small, experienced team that’s newly formed, it is almost certain to slow you down.

Beware of the bloated-process straw man

Developers who don’t want processes often cite the overhead of all the stuff listed above as a reason for not making any changes to the way they work.

News flash: sprint processes aren’t all or nothing. It’s not like the Agile Police are going to show up and arrest you for starting bi-weekly planning meetings without doing daily stand-ups.

You should view “sprints” as a distinct thing from “scrum”. Scrum is a specific set of processes for implementing sprints, but you can implement sprints without implementing all of scrum.

A definition of “sprint”

At its core, a sprint is a short, fixed-length planning iteration. This is different from other planning processes where the iterations are long or have a variable end date.

The key benefit of a short, fixed-length planning iteration is that all the tasks acquire an implicit completion estimate of the iteration’s end date, which is some time soon.

That’s it.

That one benefit is extremely powerful because it lets everyone outside the team know when they can expect tasks to wrap up and sets ground rules about urgent requests mid-iteration.

It also improves estimation for large, multi-iteration projects because you can look at the team’s track record for completing planned work (i.e., velocity not counting scope additions).

How small, new teams survive without sprints

When you’re first starting a new project or organization, things will probably go fine without sprints. A lot of teams get by with a simple shared to-do list in a place like Trello.

There are a few reasons for this, and understanding them will help you spot the early signs that it is time to start doing sprints.

There aren’t any users yet

Most interrupting work is the result of people using the product having some sort of unmet need or experiencing a problem with the product. If a product is pre-launch, you aren’t going to have customer-driven interruptions, so you don’t need a process to triage, manage, and measure their impact on velocity.

There aren’t any bugs or tech debt yet

While estimating a greenfield project comes with its own challenges, it’s much easier than a mature product, which is more like a minefield.

A process for recording estimates, analyzing their accuracy, and prioritizing improvements to drive future predictability is a lot more important once software has grown older and more unwieldy.

All the stakeholders sit in the same room

One big benefit of sprints is that they serve as a central written agreement about the priority of work. This is important for larger organizations where, for example, developers might not understand why the sales team needs something done at a certain time, and the CEO might not understand the impact of an urgent request on other priorities.

At smaller organizations where everyone is sitting in the same room, everyone shares roughly the same knowledge and it’s easier to form a consensus about what is important.

As things change, developers can easily switch priorities on their to-do list and still be working on the most important thing for the company, while everyone else in the room can see what’s happening and adjust their expectations.

When should you start following sprint processes?

Before getting into the details of when to start sprint processes, it’s important to understand that if you make a mistake and add a process too early, the impact is probably a small percentage of wasted effort and minor annoyance. If you introduce processes too late, the cost of chaos can be quite substantial.

When in doubt, a good approach is to fall back on how a process will affect morale. If stakeholders are reasonably happy and the team really doesn’t want a process, then it’s probably fine to skip. If either the team or their stakeholders are demoralized with the current state of affairs, then it’s time to take action.

When adopting sprint processes, keep in mind that there are several different practices to consider, each of which may be appropriate at different times.

In the rest of this section, we look at each component of sprint processes, roughly in order of when they become beneficial.

1. Filing tickets for work

Whether you are using physical post-it notes, bullet points in a document, trello cards, or full-blown Jira tickets, this first practice looks at whether you keep a written list of tasks, whatever their form may be.

As you might guess, I recommend doing this from day one. If you don’t, you’ll have a few problems, even for a brand new project with a team of one person.

First, you’ll forget to do important things like testing key functionality or fixing bugs. Second, without writing a detailed list of tasks to complete a project, your estimates are going to be really bad.

You might be able to get by without tickets for a small school project, but any professional software developer should be working off of a to-do list in some form.

2. Estimating tasks

One of the biggest surprises for me working with customers at minware is how many engineers at decent-sized companies (20+ developers) don’t regularly estimate their tickets.

This is another practice that is usually beneficial from day one.

Assigning an estimate to each task forces you to think more carefully about the scope of work and whether the task is well-defined. I have done story point estimates even when working alone, and they have been very helpful for me.

Whenever I give a task a large estimate, I’m instantly reminded of the previous tasks that I have given large estimates and how those have turned out (not well). And if I give something a small estimate and it turns out to take a lot of time, I’ll be much less likely to underestimate similar tasks in the future.

By writing down a time commitment, estimates force developers to be self-critical and double check their plans, which helps avoid significant problems down the line.

Additionally, writing down estimates for individual tasks has the aggregate benefit of exposing project scope issues early and provides a crucial data point for learning how to estimate better.

A common anti-pattern that occurs without estimates is that developers work on marginal features at the beginning of a project. When the deadline approaches and the project is far from done, they then have to scramble to get the project out the door or push the deadline. If there were good estimates up front, then teams could have cut scope early and avoided this late-project strife.

This issue affects greenfield projects and small teams just as much as big ones, so the best time to start estimation is right away.

When estimates aren’t as important

Estimates are important if you’re building software in the traditional sense. However, there are other scenarios where estimates aren’t as critical.

The main distinction is whether teams are performing a large number of repetitive tasks (e.g., handling alerts or provisioning resources on some DevOps or IT teams), or whether each task reflects unique work that has never been done before.

In the repetitive task scenario, estimates aren’t as important because everyone knows about how long tasks will take based on previous experience.

3. Iteration retrospectives

Retrospectives are the most powerful practice for any type of engineering. They are a key part of Kaizen, as made famous in Toyota’s production system of lean manufacturing.

Regular retrospectives are probably the most important process in software engineering, and something you should strive to do from the start, even if you are working by yourself.

If you don’t pause and take time to reflect on how things could go better, it’s easy to normalize problems and miss opportunities to improve.

4. Short (1-4 week) planning iterations

One of the most strongest indicators of development productivity is work batch size, which I wrote about in What Every CEO Should Know About Software Planning.

Even if you are working on a pre-release product that won’t ship for months (like a game), shorter planning iterations are valuable from the start.

Short iterations ensure that you are delivering value in a short time frame. This gives you the flexibility to adjust plans and cut scope in future iterations.

If instead you work on everything in parallel in one big batch and run up against timeline pressure, you’re stuck throwing out work or pushing out the deadline – one of the classic downfalls of waterfall-based development.

Note here that we’re not necessarily talking about fixed-length iterations like in a full sprint process, but just about keeping iterations short as a first step.

5. Fixed-length sprints

The next step up in process rigor is fixing the planning iterations in sprints.

This is the first practice that may not be beneficial with a small team working on a pre-release product.

One downside of sprints is that they may not fit the natural cadence of work, so you could end up starting a sprint when a milestone is almost finished and have to plan out work for the next milestone when you don’t know, for example, how many post-launch bugs you’ll have to fix.

On the other hand, fixed-length iterations make development easier in a number of ways.

Having a predictable schedule is helpful for the team because they know what to expect and can get good at estimating what they’ll be able to get done in one sprint.

A fixed end date can also be your friend when you’re having a bad iteration because it forces you to stop and look back on how things are going, which lets you course-correct earlier when things are going off the rails.

I recommend starting sprints once a product is live or there are customer, marketing, and sales stakeholders. You may also start them earlier if you find the planning cadence helpful. Personally, I used them from day one working alone, but I’m also a process nerd.

Sprints help everyone get on the same page about exactly when things will be done so that people outside the team can make reliable plans.

They also help with balancing bug fixes, maintenance, and stakeholder requests against new feature development.

A common complaint that small, nimble teams have about adopting sprints is that they’re too long. Two weeks may be an eternity to wait for a fast-moving team, and a lot can happen that affects priorities in that time tame.

If this is a concern, I strongly recommend one-week sprints. We’ve been doing them at minware on our small team, and they pretty much mitigate this concern.

Also, if new information arises, you can always change what’s in a sprint. If you do this all the time then it defeats the purpose of a sprint. However, sprints can still add value if you regularly substitute 25% of the work because you gain predictability for the rest.

6. Planned velocity metrics

It is helpful to look at net velocity metrics when adopting retrospectives, but this section looks at measuring the velocity of planned work (that is, non-bug tickets that were in the sprint when it started).

The benefit of measuring planned velocity is that it lets you see how much capacity is available for new value-adding functionality.

This is something you should start looking at when the amount of time spent fixing bugs becomes non-trivial (>10%).

Without this metric, it’s easy for quality problems and technical debt to get out of hand and start significantly slowing down development. If you’re only looking at net velocity, this problem is less apparent because the team may still be completing the same amount of work.

As you adopt longer time-horizon roadmap planning, a lack of visibility into planned velocity can cause significant misses.

7. Stand-ups

Stand-up meetings are a key part of by-the-book scrum processes. The common recommendation is to have them daily.

On this front, I have found it reasonable to be flexible and adjust stand-up calls within a sprint based on the needs of the team.

The primary benefit of a stand-up call is that it helps the team leader identify when a developer is stuck and they don’t know it. If they do know it, then they can just reach out and ask for help.

However, if someone is going down a bad path and doesn’t know to ask for help, a daily stand-up ensures that it stops after at most one day.

If your team only has experienced engineers, you don’t need stand-ups as frequently.

If your team is remote, and if they are working in different time zones, stand-ups become more important.

My recommendation for stand-ups is to start a few times a week, then adjust based on the frequency of wasted effort due to lack of communication. I have been on teams where I switched from weekly to daily stand-ups, and the need was pretty self-evident due to junior developers who regularly struggled for too long.

8. Advanced sprint metrics

In a previous article – Advanced Sprint Metrics Are for Everyone – I went into detail about several more advanced metrics that can improve sprint performance, such as under-the-radar work, which measure the amount of time spent on tasks outside of the sprint.

Like with the steps here, some advanced sprint metrics are more important at earlier stages than others, and some can be helpful at the start.

My general recommendation is that more advanced sprint metrics are very important once you oversee multiple teams and can’t be in every sprint meeting. They help teams better understand workflow efficiency and self-manage when those with the most knowledge become less involved in day-to-day work.

When do mature teams not need sprints?

Working with minware customers, I sometimes encounter mature teams at larger companies using a kanban process instead of sprints, and they are doing just fine!

More often than not though, teams would do better with sprints.

How do you know which scenario applies to you?

My rough rule of thumb is that only teams doing <25% roadmap work can be efficient without sprints.

This usually implies that teams that are handling repetitive operational tasks and aren’t doing significant new feature development, such as some DevOps teams.

These teams can survive without sprints because they don’t do much planned work. Interruptions aren’t a factor because nearly all of their tasks are on-demand and, in a sense, interrupting.

Planned velocity doesn’t matter because they don’t have many roadmap commitments.

Be careful though, even DevOps teams often have important long-term projects. In this case, it might be better to use underfilled (e.g., 25%) sprints where you add on-demand tasks to the sprint and handle them kanban style to make sure projects aren’t starved for resources.

Conclusion

The question of whether to use sprints might at first seem like a simple binary decision, but it is actually deep and multi-faceted.

With the guidance here, you can better plan ahead and roll out sprint processes progressively as they benefit your team, rather than waiting until things get bad and attempting a big-bang agile transformation.

As always, my view of the world is biased by my experience, so please comment or reach out and share your story – I’d love to hear it!