Product Backlog Defense

TL; DR: Product Backlog Defense

Product backlog defense — make no mistake: Your product backlog is the last line of defense preventing your team from becoming a feature factory. Figure out a process that creates value for your customers. Moreover, have the courage — and the discipline — to defend it at all costs.

The Product Backlog in the Context of the Product Creation Process

In my keep-it-simple and thus two-dimensional product world, the product backlog defines the near-term planning as the lynchpin of the product creation process:

The near-term planning horizon in my mental model covers about four to eight weeks. It is where the product discovery phase delivers validated ideas of valuable product increments to the product delivery phase. (I shy away from calling it a hand-over as this term has a negative connotation rightfully.)

At this moment, there should be no longer doubts why a product increment is valuable to your customer and your organization — the ‘why’ question has been answered at this stage. Probably, you will still discuss the scope of the idea for its first delivery, and the engineers will think about how this product increment will fit best into the application. However, the discussion among the team members should no longer revolve around basic questions from the ‘valuable, feasible, usable’ perspective. That has been accomplished further to the left side during the product discovery phase.

If you are practicing scrum, the near-term planning will cover something between two to four sprints:

This transfer from product discovery to product delivery is a serious moment from the investment perspective. Now, the team gets real and allocates resources to product delivery, for example, the continued collaborative refinement of the related user story. Or sketches are turned into designs, and probably some preliminary work is required on the tech stack side.

Now the team becomes accountable for spending money and producing a return on investment. If you fail to deliver this return because you accepted some work that bypassed our team’s product creation process for whatever reason you will be rightfully accountable for this failure, too. And no one will be interested in reading the fine print why this happened. It is on you.

Product Backlog Defense: Expect Flanking Maneuvers to Bypass the Product Creation Process

Crossing the before-mentioned threshold is also the reason why the near-term planning or the product backlog part of the product creation process is so attractive to stakeholders who try to bypass the process and sneak in requirements or features.

Entering a competition of ideas and hoping that an idea will pass validation is a considerable effort and bears a significant risk of being rejected. The shortcut of targeting the near-term planning phase instead is hence less risky.

Typically, you can attribute a stakeholder’s attempt to evade the competition of ideas part of the product discovery phase to his or her incentives provided by the organization. Or as Charlie Munger puts it:

“Never, ever, think about something else when you should be thinking about the power of incentives.”

Agile Transition — A Manual from the Trenches

Download the ‘Agile Transition — A Hands-on Guide from the Trenches’ Ebook

The latest, 219 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches w/ Checklists” is available right here, and it is free!

The Motivation Behind Flanking Maneuvers

There are various patterns of flanking maneuvers, depending on the nature, age, and the size of the organization. For example:

• The case of the sales manager who believes his or her bonus is at risk and hence wants to throw some features urgently at the wall to see what sticks (and generates revenue) is evident.
• The case of someone who is pursuing a specific (pet-) project to improve his or her CV for the next career step — probably with another organization — is more difficult to spot.
• Often you can observe local optimization efforts by stakeholders valuing the results of his or her department higher than
• Then there is the drive to determine what the “internal software agency works on because it is our budget and we know our needs best.” Here, an organizational mindset — based on functional silos — of the industrial age clashes with the post-industrial value creation process.

If you enjoyed the article, do me a favor and smack the 👏👏 👏 up to 50 times — your support means the world to me!

If you prefer a notification by email, please sign-up for my weekly newsletter and join 16,261 peers.

Common Flanking Maneuvers

There are at least seven flanking maneuvers that make the product backlog defense mandatory for any product team:

1. Pulling rank or HIPPO-ism: There are different reasons for this kind of behavior. Some people believe that hierarchical status has privileges and rules do not apply to them. Others think that they know best, probably fueled by a paternalistic mindset. Often, it is a sign of lack of trust in the team’s capability. No matter what makes an individual behave this way, it is a sign of poor leadership qualities.

1. Brute-forcing it: The bully at work, now probably plowing through a corporate hierarchy. What worked in the school-yard might still work today — differently packaged, though. Don’t expect this behavior to leave a trail of artifacts or email threads.
2. Have daddy fix it: The magic of outsourcing the solution of ‘issues’ — here: the product team asks the stakeholder to accept the process like everyone else — to a higher hierarchy level. (‘My boss will talk to your boss, and then we will see…’)
3. Bribery: I scratch your back, you scratch mine.
4. Direct ticket creation: Why bother the product owner? He or she might be overworked anyway. Instead, your stakeholder shows initiative and creates the ticket for the required feature herself. (Not controlling access rights to the ticket system is a rookie mistake, just saying.)
5. Dispatcher mode: Why not assign a task directly to an engineer bypassing the product backlog altogether?
6. Labeling feature requests as bugs: By comparison to the other maneuvers sneaking features via bug reports is almost a thoughtful approach — someone tries to hack the system. Nice try. Try harder next time, though.

A note of caution: Do not outflank yourself during product backlog defense. The discipline to defend your product creation process from stakeholders’ attempts to bypass it needs to be applied with the same rigor within your team. For example, do not use the product backlog as a repository of ideas and requirements that might be useful at a later stage. Apply the same rules indiscriminately to everyone.

Conclusion — Product Backlog Defense

If you want to be taken seriously as a product team and if you want the organization to accept your product team as the go-to team that solves critical customer problems and identifies opportunities for the organization then defend your process with tooth and claw. Making exceptions from this rule is a slippery slope leading to becoming a feature factory.

📅 Hands-on Agile Webinars

Download your invitations:

• April 24th, 2018: Webinar #2: Agile Maturity and Agility Assessment
• May 8th, 2018: Webinar #3: Product Backlog Anti-Patterns

Note: All webinars are aired from 06:00 to 07:00 PM CEST. (That is 12:00 to 01:00 PM EDT or 09:00 to 10:00 AM PDT.)

✋ Do Not Miss Out: Join the 3,000-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it is free.

Do you want to read more like this?

Well, then:

• 📰 Join 16,261 peers and sign-up for my weekly newsletter
• 🐦 Follow me on Twitter and subscribe to my blog Age of Product
• 💬 Alternatively, join 3,000-plus peers of the Slack team “Hands-on Agile” for free.

Product Backlog Defense was first published on Age-of-Product.

Product Backlog Defense was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.