The “Big Picture Thinker” and the “Aspiring Developer”
Every Agile team has experienced the frustration of working with a Product Owner who is very well intentioned but unable to provide the clear requirements that the team needs to build the most valuable business solution.
This is the first of two articles that address the specific challenges that you may be facing (or will most likely face) in your work with Product Owners. In this article, the focus is on two of the most common types of challenging Product Owners: The “Big Picture Thinker” and the “Aspiring Developer.”
The “Big Picture Thinker” Product Owner is an epic thinker, able to give the Agile team a high level description of their requirements but unable to describe (or to decide on) specific system behavior. Their inability to provide the team with adequate detail could be due to several factors, including their limited depth of knowledge and their fear of being responsible for decisions.
Here are two techniques that you can use to drill down from the epic vision of the “Big Picture Thinker” Product Owner to achievable user stories that the team can take action on:
Ask for the story:
Encourage the Product Owner to describe a typical user experience in the system and elicit the details that the team requires by asking leading questions, such as: How would the Customer select the items that they want to order? How would the warehouse fulfill the order? What are acceptable forms of payment? Enhance this detail by asking the Product Owner to talk about the boundary and exception cases: Can Customers place same day orders? What you do when items are out of stock? How should returns and replacement items be processed? The responses that the Product Owner gives will focus the discussion on tangible outcomes, solidify shared expectations, establish priorities and, in some cases, expose knowledge gaps that need further research.
Split the story:
For each high level requirement that the Product Owner states, use these approaches to elicit the details:
- Go through the workflow steps for each user role
- Identify exceptions and variations in user types, business rules, data types and platforms
- Devolve their compound statements into isolated functions
- Clarify ambiguous verbs like “manage” or “process” to be specific actions in the solution
The following is an excellent resource to help you split user stories: 10 Useful Strategies for Breaking Down Large User Stories: (http://blog.agilistic.nl/10-useful-strategies-for-breaking-down-large-user-stories-and-a-cheatsheet/) Another technique that can help is asking the “Big Picture Thinker” Product Owner to detail the acceptance criteria for the solution by identifying measurable definitions of success for each user type. For example, When the Customer has selected all of the items that they want to purchase, how long should it take them to complete the order? This will force the Product Owner to describe specific system behavior and help to establish an agreed understanding of acceptable system behavior.
On the other end of the spectrum is the “Aspiring Developer” Product Owner who likes to describe the solution in technical terminology, stating their expectations as highly detailed system functionality with minimal reference to business requirements. Like the “Big Picture Thinker” Product Owner, the “Aspiring Developer” Product Owner’s inability to provide the team with business driven requirements could be due to several factors, including their own technical background and the previous challenges that they have had with poorly designed solutions.
Here are two techniques that you can use to encourage the “Aspiring Developer” Product Owner to focus on business-driven requirements instead of the technical details of the solution:
Build up the story:
Work upward from the technical features that the Product Owner describes to get to the core business requirements. For example: You said that you want the Customer to be able to order groceries through a browser. What will they see when they enter the website? How will they search for the products they want? What happens when they select [Place Order]? Questions like these work from the Product Owner’s point of reference, putting their technical requirements in context and providing incidental details that can be expanded upon to elicit further detail on the underlying business drivers.
Leverage Existing Systems:
Do a hands on walkthrough of similar solutions with the Product Owner, asking them deliberate questions from the end user perspective, including: What features do they like? What features are essential, “nice to have” and unnecessary? What would they improve? Ideally, there will be an opportunity for you to compare and contrast multiple solutions with the Product Owner to get a richer perspective of what they are looking for. Using existing systems as the focus of the discussion aligns with the Product Owner’s technical perspective, forces end user thinking and encourages discussion of acceptable alternative options.
One caveat is that these techniques for working with an “Aspiring Developer” Product Owner assume that the Agile team is delivering a front end business solution. If the “Aspiring Developer” Product Owner is providing the requirements for a back end solution (for example, systems integration), the technical stories that they describe could be valid. The following article from Mike Cohn provides helpful guidelines to elicit technical user stores for back end solutions: https://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems.
No matter what technique your team chooses, it is important to remember that your objective is to encourage the Product Owner to describe the requirements as realistic business-driven capabilities, not to undermine their ability to make decisions on behalf of the business.
Part Two of this series focuses on two other types of challenges that your Agile team is likely to encounter: The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner.
