Keeping a Sustainable Pace

The 8th Agile Principle addresses keeping a sustainable pace: 

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The concept of sustainable pace is not specifically called out in the Scrum Guide. However, the concept of sustainable pace is reinforced through Sprint Planning. Only the Development team determines how many items can be taken from the Product Backlog and brought into the Sprint Backlog. The Scrum Guide also indicates that Sprint Backlog scope can be modified during the Sprint by the Development Team through coordination with the Product Owner.

Working at a sustainable pace appeals to Scrum team members and development team members fleeing from traditional Waterfall project management. The whiplash effect of traditional project management as you get closer and closer to your implementation date causes stress and a feeling of helplessness as the project schedule forces the team into a “death march”. Everyone that has ever been responsible for Quality Assurance or Testing in a Waterfall project is nodding their head right now. In Waterfall projects…it is always the QA team members that are forced to “take one for team” or “do more with less”. The shift to sprinting at a sustainable pace (and yes, those terms do seem a bit at odds in the context of actual running) requires a change not only for those who make the requests but also for the team members themselves.

Product Owners (and other interested parties outside the Scrum Team):

• Don’t make commitments to the business that don’t come from the Development team.
• Don’t expect for the Development team to commit to anything longer term than the upcoming Sprint.
• All prioritization comes through the Product Owner…respect that.
• Keep in mind the cone of uncertainty when developing your Product Road Map.

Development Team:

• Beware of estimating what you can get done in a Sprint based on velocity using initial estimates instead of taking the time to break down the stories into actionable work (this is why Sprint Planning has the longest timebox of any of the meeting events).
• By taking on too many backlog items into the Sprint Backlog you endanger having the time for creative solutions, cross training skills between team members, and worst of all the temptation of accepting lower quality for the Product Increment.
• Remember, if you underestimate you can always work with the Product Owner to bring in the next highest priority later in the Sprint assuming all the original Sprint Backlog items have met the definition of done and could be released to production.

Scrum Masters:

• If you see the team overextending, ask them about this in the Retrospective. Make sure there are no external pressures on the team.
• Habitual or frequent overtime indicates an issue that you should investigate and remove as an impediment to team health.

I've been working on creating content on my blog and just had the idea to start posting the content here too.  I'll continue to do so if this is helpful to the Scrum Community.

Original article: https://soulofscrum.com/blog/f/keeping-a-sustainable-pace