12 Creative Ways to Screw Up Your Sprints

I don’t particularly like them, but it seems that sprints have the power to reassure people. It’s true that sprints are concrete.

When a team wants to work this way, I don’t discourage them; on the contrary, I help them make the most of it, even if it’s not what I would do myself. As always, it’s better for the team to draw its own conclusions, and, who knows, it might just work.

So if you really want to do sprints, do them right. And to do that, the best thing is to learn from others’ mistakes. Here, then, is a nice collection of sprinting mistakes, in other words the thousand and one ways to mess up when doing sprints. Needless to say, all of this is based on real-life experience; otherwise, it wouldn’t be funny.

❌ Exerting an explosive effort

Oh my… but why name them that? When Usain Bolt set the 100-meter world record at 9.58 seconds on August 16, 2009, at the World Athletics Championships in Berlin, guess what? He didn’t go on to run a second 100-meter race, or a third, or a fourth. So you’ll admit that we could have found a better name to describe the effort required during an Agile sprint. We’re not even talking about a marathon, because a marathon has an end, whereas a product does not (at least not in principle). The right effort for a sprint is therefore the highest effort that remains sustainable with no end in sight. It’s more like brisk walking… or just walking, really.

That said, the term makes sense if you consider that a sprint is meant to focus efforts on a business topic for a given period of time.

❌ Having multiple sprint goals

Having multiple sprint goals or, worse, one per developer, is like having none at all. Let’s recap: the sprint goal is the team’s primary focus. It helps align everyone’s efforts, preventing tasks from dragging on across multiple sprints and never getting completed. A clear goal therefore allows for faster delivery of value. This goal is most often a business one, but the team may deem it necessary to dedicate a sprint to refactoring to reduce technical debt.

The goal, then, is the very purpose of sprints. Having multiple goals runs the risk of blurring the distinction between the goals and the Sprint Backlog. Yet these are two completely different things: the goal provides direction, while the Sprint Backlog is what the team estimates it can produce in that direction over the course of a sprint.

And to drive the point home: don’t deviate from the goal, except in cases of force majeure (certain bugs or a sudden shift in priorities, but honestly, if you can’t wait a few days…)

❌ Losing focus because of bugs

A bug pops up. You fix it, it takes time, and the sprint goal goes out the window. Classic. So you start over from scratch.

Bugs have a knack for being unpredictable: you never know when they’ll pop up, or how much work fixing them will take. To address them, you need to conduct a technical investigation and sometimes a business one (many bugs reveal design flaws). How should you account for them when planning a sprint? You don’t really have a choice; you must allocate bandwidth to investigating them, by which I mean a fixed block of time. After that, several scenarios may arise:

Not all the bandwidth is used: that’s great: it means you’ll have more time to devote to development or refactoring.
A bug occurs. An investigation is conducted, and the issue is resolved right away, because it requires minimal effort.
A bug occurs. An investigation is conducted, but fixing it will require work, and the bug is deemed non-priority. It will be fixed during a later sprint.
A bug shows up. You investigate, decide it’s critical, and the sprint goal gets ditched (last resort only).

❌ Running sprints that are too long

Sprints enable three things:

Focus individuals’ efforts on a shared goal, the sprint’s objective. That way, everyone pulls in the same direction, engagement stays at its highest, and we deliver value faster.
Avoiding tunnel vision: You deploy a software increment to production at the end of the sprint in order to get frequent user feedback and confirm that you’re working on something “useful.”
A workaround for Parkinson’s Law, which states that work takes as long as the time allotted to complete it: give people twice as much time, and you won’t get twice as much work done.

So you can easily see that long sprints negate their own benefits. So what counts as “long”? In my opinion, three weeks is already too long, but one week is tricky too because you end up spending more time in meetings than actually developing. I’ll let you guess what I think is the right length 😉

In the end, a sprint is like a dachshund: it’s all about the beginning and the end; everything in between is pointless…

❌ Running sprints of varying lengths

Now there’s a concept. A sprint is a unit of time, typically two weeks, and a commitment of resources: if, at the end, you haven’t reached the goal, try to understand why and draw conclusions for future sprints. But if you extend the sprint to reach the goal, it means you’re bound by a commitment to a specific outcome; in other words, the sprint is defined by a feature scope. So it’s not a sprint; it’s a fixed-scope release. And don’t try to pull a fast one on me with the “inter-sprint” trick: declaring the sprint finished and waiting a bit before starting a new one isn’t exactly above board.

❌ Spreading a feature across multiple sprints

The smart alecks will have figured out the workaround: simply push the remaining work from sprint to sprint and let’s call it a day! And while we’re at it, institutionalize the practice by planning to spread the feature across multiple sprints, with deployment at the end. Yes, except that once again, it’s pointless, since the whole point is to go live at the end of every sprint to counteract tunnel vision and Parkinson’s Law. At that rate, don’t bother with sprints and just stick to fixed-scope releases! One thing to remember: if you want to run sprints, you need to break your work down into very small pieces, User Stories (the key: a User Story must add value for the user, meaning it must be ready to go live).

❌ Doing the development in one sprint and the testing in the next

Here again, a classic mistake. Admittedly, validating work takes time, whether it’s functional validation (acceptance testing) or technical validation (code review). Pushing this validation to the next sprint goes against the goal of the current sprint, since you won’t be able to consider your work complete (see Definition of Done). And on top of that, it puts you in a 💩 in sprint N+1, since all the time spent on validating sprint N won’t be devoted to the goal of sprint N+1. You have no choice but to plan ahead, that is, develop a little less so you have time for validation, but also break your work down into smaller chunks to spread out the validation throughout the sprint and avoid the last-minute rush at the end of the sprint.

❌ Doing the design work during the sprint

I’ll admit it: this point is a tricky one. The Scrum Guide briefly mentions “refinement” without really giving it much attention. At most, it suggests doing it during Sprint Planning. Except that if you wait until Monday morning at the start of the sprint to work on the functional and technical aspects of your User Stories, you can kiss your evening at the opera goodbye. Thus, design is Scrum’s blind spot, its great omission, the thing it never thought through. Yet it represents a significant workload and often requires back-and-forth with stakeholders (users, domain experts, etc.), or even conducting a spike or PoC. If you don’t plan for it several sprints in advance, you’ll be in deep trouble on the first day of the sprint.

❌ Running sprints without estimates (unless…)

Yes, but how can I put this: no. I frequently see teams running sprints and adding “tickets” to the Sprint Backlog haphazardly, by which I mean without any heuristics to help them determine whether the workload is realistic or not. If you’re running sprints, you need to estimate your User Stories and measure your velocity sprint after sprint…

Unless you’re using a No Estimate approach, but you don’t do No Estimate just by snapping your fingers. The essential and challenging prerequisite is that your user stories be as thin as carpaccio, meaning they’re all roughly equivalent in terms of complexity. This way, velocity is no longer expressed in story points but in the number of user stories (yes, you read that right). A relatively large number, so that mistakes cancel each other out.

❌ Estimating on a scale from 1 to +∞

As we know, estimation errors increase with the value of the estimate, because our brains process numbers logarithmically. So, if you use the Fibonacci sequence (1, 1, 2, 3, 5, 8, 13, 21…), a weight of 21 in your mind isn’t 7 times greater than a weight of 3, but perhaps only 3 or 4 times greater. Consequently, putting User Stories with weights of 1 alongside others at 21 in your Sprint Backlog makes little sense. Think about it: the estimation error for 21 could be 5, 8, or even 13! If possible, break down the User Story using the two lowest terms in the sequence (21 = 13 + 8).

It may seem paradoxical, but estimates are meant to help you do away with estimates. Your goal, sprint after sprint, should be to break down your work into increasingly granular User Stories. At first, you’ll use a scope of 1 to 21. Fine, but don’t stop there. Try moving to a range of 1 to 13, then, once that’s well established, to a range of 1 to 8, and so on. When the relative weights of your User Stories all fall between 1 and 3, you can stop estimating, because you’ll effectively be using a “No Estimate” approach.

❌ Confusing estimates with quotes

This one’s for your manager (😘) and serves as yet another reminder that words matter:

A quote is the amount of time you commit to completing a given task. This duration is expressed in minutes, hours, or days. A quote is absolute, in the sense that it is based solely on observation of the task being quoted.
The concept of estimation, on the other hand, is relative by nature: we estimate that Task B will take three times as long as Task A, and that’s it. It doesn’t tell you how long these tasks will actually take, and you don’t want to know. The only thing you want to know is that your team, at its nominal size, can handle 40 complexity points (the sum of all relative weights) per sprint, because that’s how you build your Sprint Backlog.

Estimates are therefore unitless: we don’t estimate in days; that physically doesn’t make sense. And if you really insist, I’ll ask you this: what is a day? 7 or 8 hours of work? With or without meetings?

❌ Comparing team velocities

Now that’s a great idea! As we’ve seen, velocity is the sum of the relative weights of the User Stories, so it, too, is dimensionless. Velocity is necessary for building the Sprint Backlog, but we can also interpret how it changes over time:

Upward trend: your team is more productive with each sprint. Whatever the reason (improved skills, better focus, better tools…), there’s only one thing to say: well done 👏
Downward trend: This may be due to the arrival of a new developer, in which case it should rebound soon. If it doesn’t rebound, it could be a sign of accumulating technical debt, and that’s a problem to be taken very seriously.

While the trend may be interpretable, the value itself is not. Comparing the velocity of two teams makes no sense: 40 isn’t better than 30. When such a comparison takes hold in an organization, it’s either a sign of toxic management ☠️ or an illustration of Goodhart’s law (“when a measure becomes a target, it ceases to be a good measure”).

In any case, always keep in mind that velocity only measures output; it says nothing about the outcome.

Conclusion

In the end, there are so many ways to mess up a sprint that you have to wonder whether they’re really useful or necessary. Personally, I find them artificial, in the sense that they introduce a timeframe that makes no sense for the business, and I get along just fine without them.

But let’s not be dogmatic: I’d be genuinely happy if a team told me they’re doing sprints and that it’s helping them. As our friend Woody Allen would say, “Whatever Works!”

And if you’d like to delve deeper into these topics, my course Agile with a Hammer might interest you 😊