What is a Churning Backlog?
During a sprint, the sprint backlog (which is supposed to be locked down) is consistently being changed at the request of the Product Owner — either stories are being added or existing stories are being modified to the extent that the team needs to re-plan and a large amount of re-tasking must take place. This can be caused by any of the common root causes listed below. When this happens, the team cannot stay focused because what they are working on keeps changing, a lot of waste is produced (unfinished code is waste), and the team will not be productive.
Common Root Causes:
- There is not enough planning done at a higher level, i.e. no Release Plan or Product Roadmap.
- There is no adequate pre-planning done in between sprints; this is also called backlog grooming or a look-ahead.
- There is no adequate planning done with the appropriate stakeholders, so there are ‘surprise’ requests coming from the unexpected stakeholders. This also ties in with another anti-pattern called Not Enough Stakeholders, which I’ll cover in a future post.
- The Product Owner is not fully aligned with the product release, vision, or strategy, therefore the backlog must be adjusted.
- The sprint backlog is always changing during the iteration. This can be detected through analyzing the sprint burndown charts.
- The Product Owner and stakeholders rationalize small changes. “This is just a clarification, it shouldn’t impact the sprint.” “This is the same size as X, so pull X out and do this instead.”
- The Product Owner and team continually have to split stories to get something done during the sprint.
- Pre-planning with the Product Owner before each sprint planning session, and identifying concrete acceptance criteria for each story. The ScrumMaster should be able to help to ensure that this happens.
Personal experience: When I was a ScrumMaster, I set up reoccurring meetings with my Product Owner to groom the backlog a week before sprint planning — this helped to identify questions (or gaps) the PO would need to clarify to get answers. Then I scheduled another follow-up meeting with the PO and the team to preview the stories at the top of the backlog to get a high-level estimate and draw out more questions that needed to be addressed during sprint planning.
- Help the Product Owner to establish a group of stakeholders as the Product Definition Team, and set up a backlog brainstorming and prioritization session regularly (the interval depends on the product and context).
Personal experience: A Product Owner I worked with had stakeholders scattered in different cities. He flew them into the home office every quarter, and they worked together to conduct release planning, roadmap updates, backlog brainstorming, story writing, and prioritization. This allowed those stakeholders to provide their input and enabled the PO to understand their priorities — the group worked together to calibrate their priorities, so all stakeholders had buy-in and supported the release plan.
- Help the Product Owner and business community commit to a vision statement, a roadmap, then a release plan
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.