Recovery for Scrum Sprinters

Many teams get deterred from Scrum by the requirement to start a new sprint immediately after the last on has ended. It‘s not that hard to see where the fear comes from. The prospect of constant churn without any chance for break looks frightening. Here’s a slight modification to Scrum that may not only remove the fear but bring some tangible benefits.

Well-Earned Rest After a Sprint

In one of the teams I worked with we came up with such a formula: each sprint we had a 2.5 weeks of active coding and testing followed by 3 days of rest. Of course, “rest” doesn’t mean going out for barbecue or playing video games. The team continued working almost the same as on the other days. The main difference was that during the days of rest they did not do their regular daily development. They switched activities, and some argue that switching activities is one of the best ways to recover mental energy.

The practice worked extremely well in that team. I believe, here’s why:

A bit of rest in the end of a sprint allows the team to get their breath back and release emotional strain. Work flows much faster in the next sprint after resting.

A short break allows to flush all the remaining information left from the last sprint. A team comes to a sprint planning fully refreshed, focused, and ready for a new iteration.

When there’s a couple of official resting days in team’s possession, developers are more inclined to “crouch start” the next sprint. During a short recovery period developers have enough time to prepare for the next iteration psychologically. It’s much less tempting to procrastinate in the beginning. The entire development activity becomes more transparent. Productivity and predictability go up.

A team now has dedicated time to get ready for a sprint planning. That’s when they can run through the backlog, investigate future user stories, add any missing information, and prepare questions.

Having a dedicated day (or a few days) for meetings, developers don’t get distracted from development on other days. From my own experience, on the day of a sprint planning engineer’s productivity is not even half the usual level.

At the same time, on these days a team doesn’t get distracted by coding from other important activities, such as sprint review, retrospective, sprint planning, and backlog refinement. A team may spend this time on refreshing what happened during the last sprint before the sprint review and the retro. Or, as mentioned above, refine the backlog. All these activities make team events more sensible and productive.

Having some recovery time in the end of an iteration seems pretty natural to me. It’s no coincidence iterations are called sprints in Scrum. A team gathers in a formation and then sprints flat out towards the goal. And as we all know, athletes need to recover after a run.

Typical picture: athletes recovering from an exhaustive race

More over, let’s take a look at what the Scrum Guide has to say about the duration of Scrum events. The meetings are anything but short. For instance, for a month-long sprint the duration of a sprint planning should be 8 hours. It’s less for shorter sprints, but still 2 hours for a week-long sprint is the minimum you can get practically. Taking this into account, having a day or two dedicated to team meetings and preparation for them doesn’t look that pointless any longer.

Simple Recovery Routine

So, how much time should you reserve for recovery? I would recommend to start with this simple rule of thumb:

2-week sprint — 1 day of rest

3-week sprint — 2 to 3 days of rest

4-week sprint — 3 to 4 days of rest

And then reflect iteratively on how it works out for you. Most importantly, any practice you are going to follow should be easy-to-use and bring value to the team.