1 Week Sprint Hurts. But in a Valuable Way.

Context: we are working with Scrum for ~5 weeks. The team is pretty new. There are ~10 of us, some pretty seasoned devs, but as a team, we’ve just begun our journey.

During our retro we were discussing (again!) the length of our sprint. Right now it is set to 1 week. And there are some voices in favor of longer, 2 weeks Sprint. The reason given is that:

1 week Sprint is too hectic and that it is hard to finish anything.

And the truth is, we find it hard to meet our Sprint commitments so we often end our Sprints with some tasks in Review or Doing column (which we hate!). And this leaves us with the feeling of non-fulfillment and with this persistent thought:

“It would be so much easier to finish what we’ve planned if our sprints were twice as long!”.

Well, maybe so.

The 1 Week Sprint Feels Uncomfortable.

You feel like it ended before it even started for good. If you take a new task on Thursday then you can be almost sure you won’t finish it till the end of the Sprint. The whole development cycle of coding, writing tests, performing code reviews and doing the final checks by other team members (we don’t have QAs, or to put it differently, we are all QAs) simply takes too long.

Yet, I believe 1 week Sprint is good for us. Why? Because constraints help you discover new things that you wouldn’t even notice without them. If we had a longer Sprint we might even consider we are doing OK. We might not notice that our development culture isn’t perfect.

The 1 Week Sprint Uncovers Our Inefficiencies Ruthlessly.

And when you feel uncomfortable you come with some disturbing questions and ideas. Because sitting idle and doing what you have always been doing isn’t an option anymore. Feeling uncomfortable forces you to change (or to consider it at least).

For example, let us look at how we swarm. Could we finish more if we helped each other better with coding tasks (or maybe one could code and the other could be writing E2E tests in parallel)? Or maybe we could size our tasks differently? Would it help to slice the stories in a different way and deliver something valuable in one week time instead of not-delivering the whole story during the Sprint? Or how/when we organize our slack time. Could we close more tasks during the sprint if we had someone “slacking” but at the same time being able to perform code review or testing instantly after another dev finishes coding. Would this person really be “slacking” or rather would they work hard whenever needed and in the result would make the whole team more efficient? Or maybe… and so on, and so on.

I don’t say all the ideas presented above are very bright, but I believe these kind of questions (and the discussions that follow) are very valuable. We wouldn’t have to ask them if we lived in a false belief that we are doing all right.

And that is why we stick to the 1 week Sprint for now. Because