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.