The Scrum Guide defines the duration of a sprint with one week up to a month. Most teams and companies have settled for 14 days, because that seems to be the best compromise between short and small development units and the fear of excessive planning meetings. But are two weeks always the ideal duration for a sprint?
The answer is the usual “It depends”, and that is probably what you expected, so we should take a closer look.
What do we actually want to achieve with the sprints?
Scrum helps us to live the agile principle of learning by experience. Fixed iterations are an important part of that, because they give us a structure. By the end of a sprint we examine our work done with our customers / users and draw further conclusions from their feedback (in a nutshell). In addition, we also want to create greater security and reliability for our planning by thinking in smaller units, and we want the ability to make very precise predictions for the outcome of a sprint.
These things support each other. When we get together with the customer after a work interval – after an iteration – we want to be able to speak very specifically. The larger the work package presented, the more superficial we will (have to) be, because it is simply not possible to dive as deep as necessary into things to really learn something, if there is too much to talk about.
For our considerations of how long a sprint should be, this is our first point of reference: How detailed do we want or do we need to speak to our customers? The more detailed we want to discuss, our work packages have to get smaller and our intervals shorter.
A quick word of warning, of course: We can exaggerate that too. If we spent two hours discussing, if a button should be three more pixels to the left or the right, obviously something is very wrong. Do not laugh now. Something like that happens more often than you think. Have you forgotten the last time you sat in a meeting like that, when you were lost in a seemingly endless and completely unimportant ridiculously detailed discussion?
For our frequent exchange with our customers or users we want to have exactly the right size of our work package, that is big enough to show real progress and small enough to speak in the right amount of detail to get valuable feedback without getting lost in details or superficial phrases.
The second aspect should be the reliability in our planning, because we need that for our cooperation with our customer and with our peers in other teams or other organizational units. Two parts are relevant: first, how innovative my project is, and second, how experienced my team is with this type of planning.
And forget about the second one immediately. The experience of my team is changing rapidly. If I want to do my team a favor by establishing a very short interval in order to make planning easier, nothing is achieved. After a couple of runs, our team will have adapted to this short cycle and will be able to make quite reliable forecasts. But a longer interval – maybe two weeks instead of one – will have the same effect.
Our sprints have constant durations over a long period of time, but that doesn’t mean they are immovable, that we cannot switch from one week to two weeks someday – that is possible, if there is a reason to do so. Meaning that we do not switch every two sprints. We would never achieve reliable forecasts, and for our cooperation with our customers it is not gold either.
That leaves the amount of innovation in our project as the next important point of reference. The more we know about requirements and associated tasks, the more experienced we are, giving us great amounts of security and leaving next to nothing unanswered. Let’s say, we are building a product, that we have already built in a similar form in the past. Maybe we can also be very sure, that requirements will not change drastically. Maybe the target market is very stable, the target audience very well known and also very stable. We are using technologies, we have used before and we are accustomed with. In a project like that, there is no need for a short sprint. We can go for the whole four weeks, because even the exchange with our customers will not gain many new learnings every so often.
Let’s not fool ourselves: there are projects like these in the world, and we do not have to squeeze innovation for its own sake into every project at any cost.
There are some things that are best left untouched.
On the other end of the scale, there are projects with greatest insecurities und many variables. We have to learn everything from scratch. Our customers are as clueless as we are, and all technologies are new and untested. Naturally a project or product like that would have an enormous amount of discussions involved. In a project / product like that there could be reason for a weekly exchange with my customers and also for the shortest possible planning intervals.
But the argument, we face most often, has nothing to do with the requirements of the project in itself. Colleagues are more concerned with the amount of time spent in planning and review meetings.
Seems a bit short sighted?
Of course, events will get shorter, if the duration of the sprint gets shorter, but that is not completely linear. If we need 90 Minutes for a planning in a two week sprint, our planning in a one week sprint will most likely not be just 45 minutes long, more like 60 minutes.
I am willing to invest two hours more, if that is justified by the expected outcome. I want us to have conscious decisions. For a one week sprint, instead of two weeks, we talk maybe about two hours per team member for events and discussion. In a team of eight people, that will be 16 hours, and that is quite expensive. Therefore, we cannot just simply wash away this argument. That would be most careless.
On the other hand, we are in a highly innovative project, meaning that we will spent lots of hours in discussions anyway. There is no real difference, if we do that in a planning or in a refinement or whenever. The amount of time spent speaking remains the same.
What I am trying to say: We have a conscious decision, and that is exactly what I will say to our colleagues in controlling. We are aware, that it takes time and that it is costly, but the degree of innovation of the product requires it. Controlling is not our enemy (well – most of the time). It makes perfect sense that we are reminded every now and then to be sensitive to cost and effort and time spent.
Most teams in the world have settled for two week sprints, because they are a good compromise. The forecasts for 14 days can be very precise and reliable without being too small and fiddly. My recommendation is this: In most cases a sprint of two weeks is the safest bet. If your project is highly innovative, consider one week sprints. If your project is very well known (because you are doing the exact same thing for the fifth time), go for the full four weeks. No one tries three weeks – that is just an odd number.
Forget about a month immediately. We want our sprints to end at the same day of the week. Most organizations and companies are planning in a weekly pattern anyway. Some things are happening every Monday and so on. We do not want to go against that.
Core Knowledge: The more innovation in a project, the shorter the sprint. For most teams and organizations two weeks are a very good compromise between reliable forecasts und time spent planning, while very very very well known projects with well known requirements and well known everything call for long sprints.
If you have questions left or need support in your project or your organization, let me know.
