Who Decides Sprint Length in Scrum?

Scrum teams are self-organising, so picking the length of the scrum should be a collaborative choice. If your team can't agree on a length, then the decision falls to the Scrum Master, since they're ultimately the facilitator.

There's no wrong answer to how long a sprint should be, but there needs to be enough time to;

• Plan the sprint
• Execute the work
• Test the changes
• Conduct a retrospective

Depending on how closely your team is working with the product owner (or external stakeholders), you may also need to account for the sprint to be reviewed and approved from people who aren't on your team. In our experience, this adds a significant amount of time and favours a longer sprint cadence, so the product owner has more time to get through the testing.

The most popular lengths of a sprint are one or two weeks. However, the guys over at Basecamp proposed a new scrum-style methodology they call Shape Up (go check it out!) that preaches six-week cycles since this allows more time to get stuck into the deep work required to build complex features.

There are a few variables to think through when picking the sprint length:

• Are there lots of unknowns that require the product owner's opinion?
• Is there value in meeting frequently, or is the same result achievable with a longer sprint length, less frequent retrospectives and planning sessions?
• How experienced are your scrum team, and how long have they been working together?
• How long will the product take to build?
• How available is the product owner or client?

The theory behind the sprint cycle is to create a feedback loop, so everyone working on the project is informed. If your product owner is figuring things out as they go, short sprints are usually a good idea. Having the opportunity to see the product come to life will provide them the opportunity to think through requirements they might have otherwise missed.

If your team have been working together for a while and have struck a good balance of daily communication, then going with a two-week sprint or even a four-week sprint can be a good approach. However, you need to consider how many sprints the product will take to build. If it's going to take 18 months, then four-week sprints will be fine. It's a different story if the product will only take three months to build.

What length do we recommend?

Most of our projects run on two week sprints, but we prefer one-week sprints. The availability of our clients is usually the biggest sticking point for running a tighter sprint length.

There are lots of implementation questions that come up while building complex applications. It's part of the game. The quicker these questions can be answered, the more productive and focused our team are. It sucks having an unanswered question that blocks a task from being finished.

FAQ

This is a pretty short article, so we wanted to throw in a few additional questions and answers that aren't worth dedicating an entire piece to but you might find helpful:

Q: Is the sprint length determined during sprint planning?

A: The sprint length should be agreed upon as the project is being planned and the initial backlog groomed. There's no problem determining the sprint length during the first sprint planning session as long as it's a collaborative decision that makes sense for the project's context.

Q: What does Scrum stand for?

A: Scrum doesn't stand for anything. Rather, it's a term borrowed from rugby where the players come together to restart play after a stoppage. The term was applied because a scrum requires a lot of coordinated teamwork to achieve a goal.

Q: Is scrum software?

A: No, scrum is a management methodology based on agile. The approach preaches cyclical phases of assessing a project's requirements, building, testing and reviewing. There are plenty of management software that support scrum, with Jira being the most well-known.

Q: Who creates tasks in scrum

A: Tasks should be discussed by everyone on the project team during the sprint planning session. Typically, the project manager will have written the user stories by this point to facilitate the discussion, and the people responsible for building the feature will suggest specific tasks.

Q: What is scrum vs sprint

A: Scrum is a management framework that helps teams work together. It describes the way a team should work together and the activities involved to keep a project managed. Sprints are the main tool of scrum. They're a cyclical process of planning, building, testing and reviewing small chunks of a product's backlog.

Wrapping up

Most decisions in Scrum come down to collaboration between the project team. This includes determining the sprint length. However, if consensus can't be reached for some reason, then the decision falls to the Scrum Master.

If we haven't answered your question about sprints or scrum, please leave them below, and someone from our team will get back to you in a few business days!