Search code examples
agilescrumdevelopment-process

Can burnout happen when doing Scrum sprints continuously?


I'm with a pretty small startup and we started using a form of a Scrum/Agile development cycle.

In many ways I enjoy Scrum. We have relatively short sprints (2 weeks) and I like the Burn Down Chart to track the team's progress. I also like the Feature Board so I always know what I should be doing next. It feels good taking down a feature's card from the board, completing it and then putting it in the burn down pile.

However, we are now entering in our 18th Sprint release cycle and I'm starting to feel a little burnt out. It isn't that I don't like job or my co-workers, it is just that these sprints are... well, sprints. From start to finish I literally feel like I'm racing against the clock to maintain our development velocity. When we are done with the sprint we spend one day planning the next sprint's feature set and estimates and then off we go again.

For people who work in a mature Agile/Scrum development process, is this normal? Or are we missing something? Is there normally time in a Scrum enviornment that is unassigned/untracked to get done some minor things and to clear your head?


Solution

  • This is relatively normal and can sometimes be a complaint of our team members if projects continue for a long period of time.

    The key to what we're talking about here is sustainable pace. If you and your team are able to sustain your pace over the long term, that's excellent -- you've achieve the hyperproductivity that all Scrum teams are striving for.

    Alternatively, if you're finding that you overestimate how much work you can actually get done in a day, then you may need to reevaluate that during your retrospective. The amount of productive time in a day that a team chooses to recognize when doing their capacity planning for a sprint is referred to as a focus factor.

    Henrik Kniberg has this to say:

    The “default” focus factor I use for new teams is usually 70%, since that is where most of our other teams have ended up over time.

    http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

    However, what it sounds like you're talking about is simply the nonstop momentum of sprint after sprint, not necessarily your productivity in a day. Here's some suggestions of things we have tried to deal with that:

    • End the sprint on a Friday morning. Have your sprint review and retrospective in the morning and let the team work on something else the rest of the day to clear their heads. Pick up with Sprint planning on Monday.
    • We introduced the notion of "lab days". These are entire days that the team is taken away from the project and they spend the day working on improving their own technical skills through research with each other and collaboration on specific technical topics. Most of the time they have absolutely nothing to do with the specific project and allow team members to think about lighter topics.