In my first post in this series, I described a Product Owner anti-pattern known as the Absent Product Owner. Now I’d like to introduce you to another: the Churning Backlog.
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
After being an observer at the San Jose balancing the budget game event (which was guided by Luke Hohmann of the Innovation Games Company), I realized that most of the software products that are not successful probably have something in common — the enormous gap between the customers and implementation process.
In Scrum, the customers are represented by one single role: Product Owner. An effective product owner can help bring the customers closer to the product through the iterative Scrum process, and can create a natural synergy between the implementation team and the customers. In many half-hearted Scrum implementations, the project teams and end products suffer greatly from an ineffective product owner role, and many of these projects fail. Unfortunately many of these pitfalls are manifested as common hindering and counter-productive practices known as anti-patterns. They are:
- The Absent Product Owner
- Copy The Last One
- The Churning Backlog
- The Waffling Definition of Done
- No Single Product Owner
- Not Enough Stakeholders
I will share these in a series of blog posts, beginning here with The Absent Product Owner.
Anti-Pattern 1: The Absent Product Owner
When the product owner is not available to provide rapid feedback to the agile team, the team does not receive inspection feedback and adapt their work. Nor will the product owner be able to adjust the product design or specification based on the feedback gathered from the actual customer community, as a part of the demonstrated result of each sprint. Instead, the team “self-inspects” and makes decision on their own, falling back to the waterfall process and delivering incorrect features at the end of the project.
- The product owner communicates the backlog electronically and does not show up to sprint planning or sprint review meetings.
- The team has to maintain the backlog.
- The team has to determine the stories’ acceptance criteria on their own.
The only remedy is to work with the product owner and his/her organization to:
- Create a dedicated role and support group for the product owner, so that the product owner is a full-time role on the project; or
- Designate a product owner proxy, which could be one of the team members (although this takes that team member away from implementation). Alternatively, someone outside the team can do a “mind meld” with the product owner and do their best to fill in when the she/he is absent.
If none of these options are satisfied, this impediment should be raised to the higher organizational level for resolution or it should be suggested that the project be aborted.