Preview Mode Links will not work in preview mode

Agile Coaches' Corner shares practical concepts in an approachable way. It is for agile practitioners and business leaders seeking expert advice on improving the way they work to achieve their desired outcomes. If you have a topic you'd like discussed, email it to podcast@agilethought.com, or tweet it with #agilethoughtpodcast.

Aug 6, 2021

This week, Dan Neumann and Sam Falco are together to talk about sprint duration. A common question is “How long should my sprint be?” followed by the classic consultant answer… “It depends.”

 

Today, Dan and Sam are sharing the definition of sprint and how you can decide the right length of a sprint for your team. They explore different sprint durations, from less than a week up to a month, and how to pick the one that benefits everyone on the team.

 

Key Takeaways

  • What is Sprint in Scrum?
    • Sprints are the heartbeat of Scrum where ideas are turned into value.
    • The whole idea of a Sprint is to create a done increment.
    • All of the work that a team needs to do has to take place inside of the Sprint.
    • All of the work that needs to be done to get to the product goal has to be done in Sprints.
    • Scrum is not a task management system.
  • Is there a supposed length for a sprint?
    • According to the Scrum Guide, a Sprint can be 'up to one month long,' in spite of the common idea of 2-4 weeks.
    • The scope can vary in a sprint, as long as the team is aware of their sprint goal.
  • Balancing flexibility vs. stability
    • The Leave-you-alone principle: A Sprint is an agreement between stakeholders and the Scrum team, where the first party agrees to leave the Scrum team alone to do what they require them to do.
    • One of the principles behind the Agile manifesto is the idea of sustainable development, the sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • A business can shift entirely at the end of a sprint, but within the sprint let the team work towards a goal. If there is an urgent need to change, the sprint can be canceled, which is tremendously costly and needs to be avoided if possible.
  • Different levels of projects determine different sprint duration
    • Do not forget that a team’s priority is to deliver early and continuous software delivery.
    • Dan and Sam share examples of ten three-day sprints and one-week sprints to achieve more focus on the goal.
    • Two-week sprints are the most common ones but it might not be a good length for everyone in all domains, especially depending on all the stuff that needs to be done.
    • Automated testing is a great way to save time.
    • A three-week sprint does not align with the 52-week calendar, what should you do with the extra week every month? Defying the tyranny of the calendar can be fun and motivating.
    • The month sprint can be tricky if the client, thinking that there is plenty of time, starts asking to add or change elements.
    • Ask yourself: Does your team need more time to innovate? Are you cutting quality as a result of rushing towards the goal?
    • Pick the shortest sprint length possible for your team to start with since you can always relax that a little later on the journey if it needs to be that way.

 

Mentioned in this Episode:

Scrum

Check “Episode 34: Sam Falco on Understanding the Definition of Done in Scrum”

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning

Out of the Crisis (The MIT Press), W. Edward Deming

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!