This is the second installment of the series about flavours of a product owner.
He does so because it helps him get closer to defining the value that a user story or an epic represents. He understands that users often create their own detailed mental model of a system, which is somewhat removed from the implemented model. Both the questions he asks and the answers he gets, help him discover the users mental model, and translate that to value described in user stories and epics.
To do this, he plays the “Why?”-game.
When a user tries to communicate what he wants by describing his mental model of the implementation, this POs most common response is asking why the user feels he needs the feature and asking for clarification on what the user hopes to achieve.
By asking, he is be able to identify the use case behind the request, and perhaps more importantly, the real value that the user is looking for.
With a clear idea of the required value, he can author user stories which focus on the desired value.
He can use this to communicate with the team without having to discuss implementation.
This empowers the team to design the implementation and deliver the required value with as few constraints as possible.
During the course of development, the team naturally encounters areas which require additional business input and decisions. The Inquirer makes an effort to return the teams questions and will aim to use their very extensive knowledge and understanding to return to the core value of a given user story. Does the team feel that one or another decision will contribute to delivering the value?
Is there any chance that this PO will also deliberately end a conversation with a question?
Next week we meet The Buy-in.
Asking questions is a “free for all” – at least where I work. Even further, it’s expected that you ask questions. Not because you yourself need answers but because everyone needs the answers – even the people who try to provide them.
Agile testing is one of the most explicitly pronounced mindsets for asking questions and a primary practice is asking questions early and often. It helps clarify the value in the work we are setting out to do and puts perspective and reason behind our choices.
Simply asking: “why?”, is possibly the most powerful tool you can use to gain clarity of purpose and value.
Developers are good at this. They continuously need to align with their surroundings to ensure that they share an understanding of the value they are supposed to deliver and can meet or exceed the expectations to what they produce. The implementation should on all levels reflect the value described in the user story/epic/feature, and developers know that asking “why?” helps them make that happen.
Product owners can also use this tool. Some use it a lot with clients. They know that the developers are going to present a wave of intelligent questions centered on “why”, so to be sure that a user story description already contains many of the answers, a product owner spends considerable time asking the client in turn.
That’s outward facing, the way many product owners are used to working. With more focus on asking inwards, a product owner can get much better at prioritising a backlog containing a potpourri of value from any conceivable direction.
An example is technical user stories. It’s generally accepted that these are necessary and there’s nothing to do about that. I would argue that if a product owner practices the why game with the team, technical user stories can be both non-technical and in turn make it much easier for the product owner to prioritise them. Everyone wins:
“Uhh, technical user stories. We need those!”, says developer.
“Yeah, it’s prioritised.”, says product owner.
“But…”, continues the developer “it’s right at the bottom?”.
The product owner clarifies: “Like I said, it’s prioritised. It’s more important to deliver customer value than do gold-plating of an implementation.”
Offended, the developer argues: “You just don’t understand it. It has nothing to do with gold-plating. It’s clearly value.”
“Why?”, says product owner.
Granted, the product owner probably knows that there’s user value there. He just can’t articulate it because he relates to the business side. The developer hasn’t yet discovered the user value because he needs someone to ask him “why?”.
Two colleagues, literally on the same team – searching for the same but from opposite directions, can meet where the value is, but simply asking “why?”. Everyone wins.