How to make sure they get your priorities

June 6, 2008 by Artem

In the absence of market facts, he who owns the compiler wins. © Steve Johnson

If you are on the customer side of a project (for example, being a Scrum Product Owner or a person above him) you might have experienced a situation, when you ask team for building features A, B and maybe C, and the build C, D and a bit of B, "because they thought D was more important for the user".

Theory

Scrum theory on the customer side is simple. Formulate your requirements in a list, team commits to what it can, implements the committed items during a sprint and in the end you accept or reject what they managed to come up with.

Ok, being a good product owner you don't separate yourself that much from the core team. You regularly groom the product backlog together with the team and during the iteration help the team understand what exactly you want, but the process still revolves around listing requirements and accepting/rejecting their implementation.

Real world

In reality the team is rarely blindly executing the requirements. Most of the good teams are actually willing to make the end user happy. Then they anyway know that the backlog is just a mean for building the satisfying product and the priority order might be just a Product Owner guess on what's most important for the customer. After all they live with the solution day and night and know better what user will love doing with their software. Or do they?

Sometimes teams indeed understand the customer wishes better, than PO does (and that could be a good hint to send him to some studies), but most of the time it is an illusion. Nevertheless teams often try "helping" the situation in order to develop the software they are sure customer wants.

Basing on the facts

The will to help the project is a great thing that any good manager has to appreciate. However, building the product that really satisfies the customer is also important. "Product Owner is always right" is a good rule, but it is better, to be backed up with the solid facts coming from the market research. Having decent market evidence for your requests is even more important if you are not the team Product Owner, but e.g. Product Manager with most of communication flowing throw the [proxy-]Product Owner.

Otherwise, he who owns the compiler wins.

Permalink