Those in the agile community probably all heard about refinement meetings. But what is it about, and what potential still slumbers in it?
And while we are talking about it: who has heard of, let alone actually worked in a product trio yet?
We think that there is considerable value to be added when putting a little bit more effort and focus on the refinement, than is usually done, by combining it with a product trio approach. It can be quite a time investment by a lot of people. But at Spaceteams the approach has already paid off in many situations.
What is refinement?
It used to be one of the scrum events until it was removed from the scrum guide in the version from 2020.
Refinement itself is still mentioned and explained in the scrum guide as:
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”
💡We think there is a lot of potential in the refinement process of user stories and backlog items, that can be unleashed when going beyond the basics and combining it with the approach of the product trio.
What is the Product Trio?
Teresa Torres, author of Continuous Discovery Habits, described the product trio in the context of product discovery as:
“A product trio is typically comprised of a product manager, a designer, and a software engineer. […]
A product trio is jointly responsible for a shared outcome. They interview customers together. They map out the opportunity space together. They choose a target opportunity together. They generate solutions together. And they iteratively test and develop those solutions together. […]
When a product trio works together to develop a shared understanding of their customer, they are in a much better position to create products that customers love.”
Why combine refinement and product trio?
If the product trio is considered useful for discoveries, then why is it helpful in the context of refinement, which happens after the discovery is done?
In our project reality we are typically building some custom software as part of a value chain and rarely a stand alone product. This means we need to understand users, align with upstream and downstream systems while supporting to reach the overarching company and business goals, e.g. restructuring and automating business processes.
This means that there are a lot of different people to talk to for different aspects of the required feature set of the system. In these settings it is often difficult to find the time, or the budget to bring a product trio together for a proper discovery. The PO has to use any chance they get to find out requirements and needs and bring it back to the Dev team.
And this is where the refinement comes into play.
Sometimes the PO brings a backlog item, usually a user story, that is incredibly detailed, in some cases even including implementation details. And other times the story is barely self-explanatory.
Most POs are not developers. And typically a PO is only one person.
So why not use the brain power of the whole Dev team during refinement to question the user story, with respect to known pain points, added value of the story and suitable implementation?
In our experience this has many benefits:
- The PO does not have to waste time trying to specify a story to the last detail
- The whole team gains a detailed understanding of user needs and requirements
- The solution to the user need can be looked at not only from a business side but also considering technical opportunities and restrictions
- The increased understanding
- often allows for a smoother implementation
- and reduces alignment needs, follow up questions and discussions during implementation
What hurdles need to be overcome?
The product trio approach on its own is already difficult to put into practice for many reasons. Time and budget constraints being the most obvious. Which company or customer is willing to pay for meetings with large groups of people, especially when those people seem to be better employed doing other things, e.g. the devs should be coding? If such a meeting took place it would need to be moderated very well to make the most of the time invested (but what that means can fill an entire blog post on its own).
And then there is the human factor. The PO, the UX/UI Designer and the dev team all have their roles to consider, their metrics that their work is measured against and maybe also their own agenda. In the best of cases all of them want the best for the customer. And still this does not ensure that they have alignment on what the best actually is.
In our project work PO, Designer and dev team are often working separately. They are not - or do not act as - one team. The designer is often responsible for more than one team and has only very limited time to spare for alignment meetings. The PO is deep into discovery, company politics and navigating the different needs of stakeholders and users; sometimes struggling to fill the backlog in time as it is.
So why bother?
With hurdles like these, coming together on a regular basis to spend time on refining user stories, which in theory the PO could write on their own, there have to be really convincing and strong benefits to outweigh the investment.
We believe it is worth it!
Not only because of all the reasons stated before about understanding the product better, improving the quality of the outcome and reducing friction during development. But also because it significantly increases the ownership the dev team takes for the product.
We value ownership very highly at Spaceteams.
It is the strong sense of ownership that drives us to want to understand the products we built, that pushes us to make them as good as possible within the timeframe required and most importantly to stay focussed and deliver.
In our experience the results prove us right. The quality of the solution is better when we carry refinement out in a product trio style. And all that is built is then much closer aligned with the overarching company goals of our clients.