An experiment that may help your team not to turn Scrum into an endless churn.
Recovery for Scrum Sprinters
About the Author
Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer.
Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer.
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:
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.
Typical picture: athletes recovering after 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