Everybody has pet requirements and product owners, being human, are no different. Unfortunately pet requirements are a real risk to software projects. We should all resist these pet requirements and do everything possible to kill them off ASAP and avoid building them. So how do you spot pet requirements

What is a Pet Requirement?

What is a pet requirement? Pretty straight forward really. The product owner is attached to these requirements but the wider business isn’t asking for them because they don’t bring business value.

I see two types of pet requirements which I characterise as benign (or at least largely benign) and aggressive.

Largely Benign Pet Requirements

Benign pet requirements lurk for a while on the product backlog / release plan but never quite make it onto the agenda – never make it to the top of the list. The common pattern is that new items appear and get escalated above the pet requirements. It happens again and again. I call these “benign” because although they shouldn’t be there they are not going to kill you.

Benign pet requirements usually appear in two places on the priority list / release plan / product backlog:

• At the bottom. This is a sign the product owner subconsciously realises they are the only person to care about these requirements. Despite this the product owner still hasn’t accepted the requirement isn’t real. It can take a while for this realisation to happen.
• Floating just below the top but never quite get there. They are often cards that start as a “Must have” items. But in competition with real “Must Have” items they turn into “Should have” and eventually “Would like to have” items. Again this can take a while. In fact this type often turns into bottom dwellers before they are finally removed from the list.

If the product owner is at all self-aware there is a good chance these pet requirements will never make it to the top of the list, will never get built and will in due course drop off the list completely.

Although benign, they are not going to kill the project, these requirements are still a problem because it takes team energy to process them while they remain on the list. Every time prioritisation comes around the pet requirements are considered against real requirements, there is discussion, perhaps estimation, perhaps UX design, perhaps a spike. Despite this work, or perhaps because of this work, the pet requirements remain on the backlog undone. If they are never going to be done we should remove them saving the team from the processing overhead.

Aggressive Pet Requirements

Far more dangerous are the aggressive pet requirements. Actually the requirements aren’t aggressive, the product owner is. In this situation the product owner is going to force their pet requirements through regardless.

You can spot these because the product owner is not willing to be challenged on them and they result in features that are unused. Of course by then it is too late – you’ve built them.