3 Tips for Product Owners to Survive the Chicken Test

As a Product Owner, why should you even think about the Chicken Test?

For a simple reason: You are accountable for ensuring that the product you’re working on achieves its goals.

The chicken and pig metaphor suggests that the difference between ham and eggs is this: the hen is involved, but the pig is committed. While Chickens may have other priorities, pigs have only one goal – make the project successful.

When it comes to Scrum, surviving the Chicken Test means that the Product Owner is not treated as someone who is not a member of the team.

Theory says that the Product Owner is a pig, committed to the project and judged on the results. However, the role of Product Owner is the most critical one in terms of conflicting priorities.

In practical world, often the Product Owner role is assumed by someone whose primary job is to directly face customers or interact with other critical stakeholders and in such situations, the scrum team may feel that they are interacting with a Chicken when they are communicating with the Product Owner.

When the Product Owner is treated as someone outside the team, there is a high probability that not the Product Owner’s other responsibilities but his behaviors are making the team uncomfortable.

It is obvious that most people don’t like to be with people who make them uncomfortable. Scrum teams are no different.

Team being uncomfortable with Product Owner is an impediment as it can impact their ability to deliver.

The team will react using more or less predictable behavior. You will be treated like a Chicken. Your inputs won’t be appreciated in daily scrums or retrospectives and the level of comfort will be less amongst the team members when you are around.

The result? Conflict among team members. Demotivated team.  Ineffective sprints. Delayed release cycles…

No Product Owner wants that, do you?

Here are my three Tips for Product Owners to Survive the Chicken Test

1. Honor your agreements:

Product Owners often get situations where they have to obey other commitment at a cost of the commitment they have made to the team.

Particular instances could be as small as promising and not meeting daily scrum or as critical as delegating the huge part of Product Owner’s responsibilities to a team member but the point is – the agreement is dishonored.

Don’t do that. Always honor your agreements.

The team cannot trust a Product Owner who does not keep his promises.

If the team cannot trust the Product Owner, the very essence of Scrum is compromised.

Don’t make agreements that you cannot honor. Period.

2. Exhibit unconditional commitment:

Let us face it. Almost all Product Owners are committed but not unconditionally. At least not always.

They may attend all the Daily Scrums as agreed but may not always pay attention to the junior most team member’s point of view.

Even if the junior most team member is not adding much value at the very moment, she at least deserves all the team members’ attention.

That is very basic but often not practiced as it should. Now, that’s an example of lack of commitment.

So how do you deal with that? Don’t choose to be the Product Owner if you cannot offer unconditional commitment for the project.

You may be an important stakeholder or the core Project Sponsor but you cannot be the Product Owner if you have any other priorities than making the project successful.

Have unconditional commitment if you take the Product Owner Role.

3. Make yourself available:

If you are NOT available when needed, it is often perceived as lack of commitment. When it comes to be part of a team that has ONE goal, managed perceptions are much better than assumed conclusions. None other than Product Owner can own that fact.

For any clarification or insight the team might need, Product Owner has to be available for the team.

There is an another aspect of making yourself available. You make yourself available to the team when you develop a personal rapport with team members such that they don’t hesitate to ask you questions. If team members do not feel closeness, changes are very high that they won’t consider that the product owner is available.

At the end of the day, as a Product Owner, you have to deliver the results. You’re rewarded if you do, you’re fired if you don’t.  If you don’t pass the Chicken Test, you need to work on yourself. If that’s the case, don’t wait, go fix it.

The Problem With Preparing User Stories In Advance

is that it lacks the “ownership” part.

Some Product Owners invest a lot of time creating user stories and provide them to the team in the sprint planning meeting.

It is an opportunity lost to explore team’s point of views and knowledge.

Stories created through such activities often serve as meaningless piece of document in the greater whole.

A good user story is complemented by the team talk. It is more on target when it is written collaboratively. A user story should be able to convey the essence of the story, not every single detail that can be imagined around the story.

The lean concept, “just enough” applies while creating user stories as well.

When it comes to grooming your backlog and envisioning the future of your product and organization at large, user story, when done as a team activity, has potential to produce wonderful results.

Don’t engage in an Agile activity just because it is a ceremony. Get the essence of it and practice it in the right way.

Great user stories are user stories that are owned by the team. If your user story has not got 100% ownership, something is wrong that needs to be fixed sooner than later.