3 alternatives to the 2-week sprint

Most Agile teams nowadays are using 2-week sprints. While it allows faster shipping, it comes at the expense of more planning, compromised quality, and ultimately developers burn out. Let's look at alternatives.

Most Agile teams nowadays are using 2-week sprints. While it allows faster shipping, it induces more planning, compromise quality, and ultimately leads to burn out. Let's look at alternatives.

Dual Track Agile

You need to define the outline of the solution before the sprint starts. Usually, it's done in a meeting as the sprint is about to start. In reality, it's not enough time. Some features are going to be abandoned during the sprint resulting in wasted time and lower motivation.

To overcome this issue, more and more teams are adopting dual track agile. The discovery track allows designers and product managers to validate ideas and problems to solve and create a backlog for the delivery track that will allow the developers to build higher quality shippable software.

1-day sprints

Shorter sprints mean shipping and getting feedback faster, and feel more rewarding. That's why many teams are using 2-week sprints. But how to avoid the common pitfalls?

John Cutler is proposing 1-day sprints. You start the day with a conversation to come up with something that can be delivered by the end of the day. You figure things out and ship something. Then you repeat it.

This is a way to do the discovery and the delivery at the same time in order to deepen your understanding of the system. If things seem stale, this might be a way to quickly make everyone feel energized again. Less planning, less micromanagement, and more shipping.

6-week cycles

The last alternative I am going to talk about here is from Basecamp. They are doing long cycles to let their teams define tasks and implement however they see fit within the cycle. Less planning means product managers get more time to focus on other activities like research which will, in turn, improve the predictability of the next cycles.

Conclusion

Giving more time to figuring things out is at the center of all these alternatives. It reduces uncertainty and increases the quality of shipped features. Everyone is happier with less micromanagement. Don't feel obligated to use the most popular methodologies and find what works best for your team to make the best software possible.