Sprint Backlog is NOT a parking lot

Sprint Backlog

Lets start with the #singlesourceoftruth for Scrum: #scrumguide

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

Further:

The Sprint Backlog is a plan by and for the Developers.?

Those familiar with #agilemanifesto - can recollect one of the value statement:

Responding to change over following a plan

Its #explicit that in #agile #waysofworking - flexibility with the plan is more important than having a #rigid #frozen plan.

Let's begin with Sprint Planning

The background for this article is a situation faced by a #scrummaster. In Sprint Planning, the #po emphasizes on several PBIs to be taken up during the Sprint. Even though Developers highlight that volume of work is much more than their planned available #capacity - still PO pushes several PBIs. (I know this is an anti-pattern from Scrum Guide - i.e. PO pushing PBIs instead of Developers picking it by themselves, I am presenting it as narrated by the Scrum Master.) This Scrum Master tried to have a conversation with the PO, #educate the PO about what #scrum says. He tried this over 3 Sprints. But PO was not listening at all.

Lets look at the data about selected PBIs in the Sprint versus Done PBIs for these 3 Sprints:

Two major impacts of the above situation

1. Several PBIs will not be #done during the Sprint, making spillover inevitable in each Sprint
2. Predictable value delivery will not be consistent, making it difficult to plan, release value

The impact of Spillover PBIs across Sprints

• Lot of effort goes into re-estimating and replanning them - if they were to be completed in subsequent Sprints
• The ability to work on more relevant or next set of high ordered PBIs from the #productbacklog will be severely reduced
• Over the long run, Developers may become demotivated impacting #transparency of the Sprint Backlog

The impact of inconsistent predictability of value delivery

• Stakeholders and anyone interacting with PO for their requirements, features, enhancements to be delivered will not be able to plan when the will get their work "done"
• Developers may be forced to get into #techdebt #intentionally to meet the delivery predictabilities
• Sponsors and/or investors in the product (or project) may develop a feeling that their investments are not delivering enough #roi in required time

What can a SM do in such situation?

Presenting one approach - which I discussed with the Scrum Master. There could be other ways to approach this situation. Feel free to explore or you can share it in comments for the benefit of larger community.

One final time, from Scrum Guide:

... the Sprint Backlog is updated throughout the Sprint as more is learned.

1. Have a courageous and open conversation with the PO backed by the data. Don't be afraid to reach out to anyone - (for example - even someone higher than the PO who may understand your view point, Scrum ways of working) - so that correct message is shared across
2. Check with Developers on exploring #kanban concept of #wip #limits. Coach and help them.
3. Propose and convince to run an experiment for next 2 to 3 Sprints - where Developers select PBIs that they can get to "done" in the Sprint. Inspect and adapt as necessary. Be transparent all the way.

Conclusion

Sometimes, the way people (they can be anyone - within #scrumteam and #outside as well) #interpret, #understand and #practice Scrum could be not as per Scrum Guide. When a SM encounters such a situation, without compromising with the thought that "it's [the anti-patterns] working for me here, why I should disturb it" - SM should be courageous, focused, committed and respect Scrum as per Scrum Guide.

Scrum Master's accountability is establishing Scrum as defined in Scrum Guide

If this is not met, time for an #introspection

Thanks for your time coming this far. #rawagility