Sprint length: is shorter always better?
At the Sprint Retrospective, team “Winterfell” is discussing the Definition of “Done” and the Sprint length — again. This must be the 6th time in the past 4 months. The topic is an energy drainer. But Henry — the Scrum Master — will not let go of it. As soon as he got the opportunity, he jumped on it. It’s his favourite topic.
“Let’s take steps to increase our agility”, Henry says. “I believe that we need to get our product to the users as fast as we can to receive valuable feedback. So this is why I strongly recommend to find ways to expand our Definition of “Done” (DoD) to get our functionality in a production environment. This allows us to receive real user feedback. And we need to shorten our Sprints too. I suggest to first work on the expanding the DoD and when we have established that to move to shortening the Sprints.”
Carla is one of the members of the Development Team. Henry respects her, but he also believes that she doesn’t get it. So he is annoyed when Carla responds: “I believe that our current Sprint is too short already. We don’t have time to experiment with our approach and still meet the Sprint Goal. Instead we now choose a certain way and hope it works. While we learned that a better approach is to try multiple scenarios and then pick what worked best”.
Henry answers: “But don’t you agree that we should expand our DoD?”
Carla: “Yes I do. But I believe that this means we need to have longer Sprints. We should be moving from two week Sprints to three week Sprints — or even four week Sprints. By doing that we should be able to have the first user feedback within a Sprint”.
Henry is taken aback by this. Especially because the other members of the Development Team nod in unison. He responds: “This only means that your items are too big. I advised you before to slice the items into smaller pieces, but you haven’t done so. As a result you are never “Done” at the end of the Sprint. Increasing the DoD will force you to be more creative.”
Then Sandeep — another member of the Development Team — says: “it’s not that easy. We typically can’t slice our items. More often than not they are already as small as they can be. If we slice them further we will not deliver anything of value anymore. Only pieces of an unfinished puzzle.”
Henry shrugs his shoulders. He decides to keep the status quo. He will not discuss expanding the DoD anymore as long as the team then wishes to expand the Sprint. Which is the worst thing he can imagine.
Is shorter always better?
So who is right? Perhaps we don’t have enough background information to know this. But more important than answering this question is the following:
Are shorter Sprints always better than longer Sprints?
Within the Agile community it is a given that it is important to have frequent feedback on what you have built. This is why the Manifesto for Agile Software Development (2001) has the following principle:
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” — Principle behind Agile Manifesto
This is completely in line with Scrum. After all, Scrum has Sprints that take a month or less. And a Sprint is about delivering a “Done” releasable product increment.
But… does this fit with what Scrum is intended for?
Complex adaptive problems
To begin to answer this question, let’s start with what Scrum is:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017
Complex and adaptive. Two magic words. In a complex environment you need to be able to adapt to new insights. And it’s best to adapt as soon as you have these new insights.
Sometimes the feedback can be given on tiny add-ons to the product. This will allow you to have short feedback cycles. In Scrum this would result into having short Sprints.
I see a risk in this approach. By focusing on delivering small increments there is a chance that the overall picture isn’t considered, ending up with a feature factory: focusing on fast output instead of valuable outcome. This is certainly not what our Scrum Master Henry wants to happen!
Short feedback loops require dedication and focus, drawing lessons from the increment and adapting every single time. Imagine doing this every day. It’s hard work. But I digress.
There are also product environments where more time is needed to make heads or tails of it and to understand enough to make informed decisions. These environments aren’t helped by slicing the items to smaller pieces, because there will be nothing meaningful to slice at some point. Contrary to popular belief, there’s nothing wrong with having bigger chunks of work. As long as the items are as simple as can be (the art of maximising the work not done — Manifesto for Agile Software Development). Remember that:
“In complex environments, what will happen is unknown.” — Scrum Guide 2017
Fast feedback beyond the events
There is one other perspective to consider: are shorter Sprints required to get faster feedback? Sure, shorter Sprints mean more Sprint Reviews which means more opportunities to inspect and adapt together with stakeholders. But releasing and collecting feedback during a Sprint can still be done, unless company policy prevents this. (courtesy to Sjoerd Nijland)
Henry, our Scrum Master of the example, has the right motives when he wants to have actual user feedback as fast as possible. However, what is actually possible depends on the product environment. Some environments allow you to take tiny steps and receive feedback almost continuously. Other environments have different characteristics that require more digging and experimenting to create an increment.
So while Henry’s motives are great, he forgot to verify the characteristics of the product environment of team ‘Winterfell’. And he didn’t want to accept the feedback from the Development Team.
There are no straight answers here. This is why Scrum welcomes experiments by trying something out, inspecting what the impact is and then adapt based on new insights.
But don’t base your actions on assumptions — like shorter Sprints are always better. Base them on what you learned from your experiments instead.
And also: Scrum doesn’t rule out releasing and collecting feedback during a Sprint.