When the Product Owner Has to Say No

Saying no to the team, to the client or the Scrum Master, is one of the PO's more important tasks, but let's think in some situations when this might happen:

1. When the team wants to force the client to use a technology, platform, architecture or design that it believes that is "technically suitable" but has no value for the client -I know what is best for you syndrome-
2. When the client wants something that is clearly unfeasible with the given schedule and resources -the dreamer syndrome-
3. When the Scrum Master representing the team wants to change the scope for the project -two captains one boat syndrome-
4. When the team voted and decided what should be excluded from the product -technical decision without business support syndrome-
5. When developers want to work on an overkill solution for a problem -super engineer syndrome-
6. When the team wants to investigate during several sprints without guarantying practical results -researcher syndrome-
7. When the team and Scrum Master want to skip demos -ostrich syndrome-
8. When the team want to exclude the PO from all meetings because they believe they already understand the product well enough -come back when it'll be ready syndrome-
9. When the client want to communicate directly with the team bypassing the PO -serve yourself syndrome-

Syndromes Origin

Even though these syndromes are very common, their origins are still fuzzy, some might be:

1. The PO is not making a good job gathering requirements
2. The PO is not making a good job communicating requirements to the team
3. The PO is not making a good job tracking Sprint progress and backlog evolution
4. The PO is not making a good job interfacing with the Scrum Master
5. The PO is not making a good job buffering the team from external influences
6. The PO is not making a good job setting priorities
7. The PO is not making a good job using her charisma to lead/influence the team/client in the right direction

Whatever reason that is forcing the PO to says no to the team, these seems to indicate a disruption in the PO role an performance. After all a NO is not required if everybody is clear in what should be done.

Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance. But in any case is times better that the PO says no and correct her course than letting things flow in a direction that will take the project to a failure.