Product Owners don't cut Wood

Does this sound familiar to you? There is this backlog grooming session every week. The product owner would present his user stories. They have title no one in the room understands. They follow the Connextra template of as-a I-want-to so-that. When reading this you sometimes feel like you get a notion of what the title of the whole thing may have meant to mean, but it doesn't grab a hold with you. It just keeps slipping away. And there are these acceptance criteria. In full detail. Describing a solution to a problem that you do not fully understand. Somehow you come to think of it as yet another more or less farfetched special case that has to be added. Everything the product owner tells the team about this story is so rich of detail and so deep into the "How" of it that it resembles a specification. Did I mention that this is the first time you would hear about this particular story?

You feel like you would like to know what problem should be solved, what the customer would like to be able to do, what context this case related to. You would like to know that big picture thing but all you get is tons of technical detail. You feel lost and drop out of conversation.

Ever made this experience? No? Lucky guy you are. The whole thing wouldn't be too bad if it would just be wasted time spent in a boring meeting. But it's worse than that. There are two options.

First the team ignores the very detailed spec like acceptance criteria when implementing and the product owner barely checks what he really gets. The consequences are that the product owner thinks he has got a certain product but the team built a slightly different one. His understanding of the product will run out of date and so do his user stories.

The second option. The team actually builds what was requested but does not take the responsibility for the product. The product will start to resemble a bunch of special cases. Similar things are not done in similar ways. Features start to become mutually exclusive. (Yes. This could happen. Have seen it ...) And the code base reflects this. Adding new features takes longer every time. Even minor changes take ages. Bug rates increase. You are in a mess. You know you should clean this up. But you don't know the direction or any direction at all for all you know about the problem space is detail.

In both options the team will have a hard job to build an identification with the product they build.

Cutting Wood

Do you smell the smell? What's wrong here? Taking it to an analogy the product owner takes the team on a tour to the woods. They walk around and pick a tree to cut, and another, and another. Here and there. Randomly it seems. Then he picks them all up and drops them in another forest where they pick another set of randomly chosen trees to cut.

No one has any idea about what made the tree so special to be cut and why the tree next to it did not qualify. No one has any idea about where they are how they got there in the first place. They know the trees they’ve cut and for there is no real memorable connection between they might have forgotten about a number of them.

What the team misses to see, is the landscape around them, the patches of trees, the forests, the meadows and creeks, lakes, hills and pathways that form the world they have to move in. They have no way navigating their surroundings on their own. They depend on their guide. The depend on their product owner to tell them what to go for next.

This puts the team in an uncomfortable position. It cannot fulfill the role they are supposed to in Scrum. They are not in a position to act at eye level with the product owner.

Shape the Landscape

To stay in the picture the product owners job is to shape the landscape to develop a big picture of where to place a forest, a lake, a creek. Where to lay a path or spread a meadow. The detail work will be done by the team on its own account. If a forest shall be then trees have to be planted. If there has to be a simplification some trees have to be cut.

The team always sees the tasks in context with what else is required. They can bring their detail knowledge to the big picture to help refine and adjust it if needed. They have the chance to understand connections between tasks and might offer shortcuts or optimizations.

What a Product Owner should do

The job of the product owner is to take care for the big picture of the application to be built. She has to balance the sometimes conflicting requirements. She has to balance the stakeholders to keep them happy and satisfied with the product and the way it moves on.

The product owner has to serve as the on-site customer for the development team. She has to convey the requirements and the context they come from to the team. She has to understand the problems that should be solved and what the customer really wants to be able to do. She is the person that connects the team to the problem domain and has to make sure the domain and its terminology is known by the team.

Especially the last one. User stories should reflect the problems within the domain language. Acceptance criteria have to use the domain language to describe what should be possible when implementation is done. The product owner is a major player in building the ubiquitous language both the customer and the development team understands. Just as described by Domain Driven Design. Using this ubiquitous language opens up opportunities for the team. It offers possible abstractions they could use in their implementation. Something a very detailed and technical description of the problem never could provide. It helps the team to see connections between features and to further drive abstraction in the code. And with that it helps to improve extensibility and maintainability of the code make sure the speed of feature development could be persisted over a long period of time.

In a way one could conclude that the way a product owner writes his stories she could drive a healthy code base or a horrible one. It depends.

Read also:

On Coaching Agile - What I've learned from being an agile coach

On Sporadics - How to deal with intermittent tests in continuous delivery

On Agile Testing - Do we need testers?

The opinions expressed in this blog are my own views and not those of SAP