The most important aspect of a sprint length is consistency, no matter the duration of the sprint. If you established a sprint length of 1, 2, or 4 weeks, then that’s the time range you want to continue with.
But let me show you why shorter sprints are more effective and what benefits this can bring for the entire team.
1. Shorter iterations allow teams to inspect and adapt more often
- Teams will identify problems and discuss them earlier
- The solution to these problems can be implemented sooner
- Things that worked well anchor faster in the habit of the team
Each sprint ends with a Retrospective session. The benefit we see with frequent inspection is that teams get the chance to identify problems faster. Which leads to faster improvements. When we choose to work with longer sprints, it is more difficult to consider all the events that took place during the sprint.
Many of these issues are forgotten, or overlooked, which means that there will be important issues that we will not discuss. And only the last events will be taken into account because they will be the freshest in everyone’s mind.
However, we are not just talking about the problems that have arisen. There will be things that work well in the team. We must also identify them in time to continue to be applied.
2. Sprints with a shorter length make planning much easier
- The Sprint Planning session doesn’t last as long as it would for a 4 weeks sprint
- The items that are planned in Sprint Planning are more likely to get done
- The Sprint Goal is clearer for everyone
- It keeps people more focused
Long meetings are tiring, and we often lose focus. For a 4 weeks sprint, we should spend 8 hours in Sprint Planning. And spending so much time in one meeting reduces the productivity of the team and the capacity to make the best decisions. I’ve seen many times people trying to make the most convenient decision just to get out of a meeting.
With a shorter sprint, the Sprint Goal is easier to reach because there is no time to get lost in insignificant details. It’s easier to create short-term goals and step by step reach the larger goal by putting together all the resulting work.
3. The feedback from the customer or Product Owner is more frequent
The feedback can come from the Product Owner sometimes, directly from the client or from other departments. It depends on the structure of your organization. But no matter who is giving you feedback, receiving it is so important. How else can we know if we are moving in the desired direction or not?
The earlier we get feedback on what we do, the sooner we can inspect the outcome and determine further adaptation. When we don’t get frequent and early feedback, we can work for months on something that might not be as the Product Owner imagined or needed. And it means that we would have invested time in something that doesn’t bring the value he envisioned.
There is a dedicated event for inspecting the results of the work, which is the Sprint Review. However, that shouldn’t be the only moment when the team gets feedback, it should happen throughout the sprint as well.
As a Product Owner, I used to offer feedback to the developers at least twice per week, or every time they asked for it. And the Sprint Review was when we would show the work to other departments that were working closely with the customers.
4. No mid-sprint changes
With longer periods of time, the probability of introducing changes in mid-sprint is high. And this happens because, throughout the sprint, the Product Owner can come up with a whole new set of requirements. The market that is constantly changing leads to these modifications. That’s because the client will always want to make changes for the product to fit into the current market. This can change the priority of items that are already in the sprint.
Two things can happen in this situation. The sprint either gets canceled, or the team will have to rush things to fit the recent changes. Changes mid-sprint have a big impact on a team’s focus, which can lead to failing to deliver the desired value or meet the sprint goal.
With shorter sprints, this is less likely to happen. The feedback is frequent and the Product Owner has the opportunity of understanding the product better. This can help him make more informed decisions.
5. Early and frequent deliverables increase the ROI
Why do early and frequent deliverables increase the ROI? When a piece of functionality gets to the market, we have relevant data that tells us if it satisfies the client’s needs. Or, it shows us if it was a poor decision to invest our time in developing that feature. It’s also an indicator for understanding the changes we should do to match with how the users are intending to use the functionality.
More than that, when we have a large time span and we deliver something at the end, we’ll get a return only at the end of that time period.
What happens when we deliver frequently pieces of the product? Even if they are small pieces that compose the entire functionality, we’ll have a return throughout the entire process of developing the product.
What happens with longer sprints is that we can complete features toward the beginning of the sprint. And we have to wait for the entire cycle to end to also go to production.
6. Team satisfaction
In shorter sprints, teams are more focused. It happens because they are more likely to remember what each work item entails. And they can keep track of the status of each working item.
So teams working in a sprint of short length will deliver more quality and this gives them more satisfaction. Not only that but also frequent delivery and feedback play a role in the quality of their work.
And it is also about the fact that the teams see their work delivered and used. With long sprints, it is often possible for some of the functionality not to be delivered to customers because of the changes in the market.
Final thoughts
Although shorter sprints have more benefits, long sprints also have their pros and sometimes they work too. For example, it’s easier for new teams to work in a 4 weeks sprint when they practice Scrum. In the beginning, it’s more difficult to deliver functionality in 2 weeks, so a 4 weeks sprint allows teams to have a finished feature.
However, after a couple of sprints, teams start getting better. So we can reduce the cycle to 2 weeks or even one week in some cases.
