The power and pain of product refinement

What is product refinement and why is it important?

When a development team is equipped with an appreciation of the value they’re delivering, the whole process is more efficient and better decisions are made for the good of the product.

When working in an agile environment like we do at Apadmi, this is even more important, as the development team will be making key decisions on a daily basis throughout the lifetime of that project.

To equip the development team for this task, they need input and guidance from domain experts. These are the people who have a thorough understanding of both the end-users and the market where the product will be used. In the Scrum process, we call this domain expert a Product Owner (PO).

As part of the development process, the PO maintains a list of things that have been identified as delivering some sort of value, called the Product Backlog. It’s then the development team’s responsibility to turn this into a set of technical tasks that need to be completed in order to deliver that value.

The PO engages with the development team and is responsible for ensuring that they understand the value that needs to be delivered – this allows them to effectively break down the Product Backlog into technical tasks. This part of the process is called ‘Product Refinement’.

What does our product refinement process look like?

At Apadmi we’ve identified four key stages to product refinement that will help it to run smoothly and effectively. Teams are encouraged to use this as a starting point, but have the autonomy to adapt and improve upon it to suit the project they’re working on.

In our process, each individual item goes through every stage at least once to ensure it meets the criteria. Some teams have even chosen to visualise these stages in a separate kanban board, so we can see where each item is up to.

Stage 1: Prepare to engage the dev team

When building a house, the foundations are the most crucial element – and it’s the same with product development. To kick things off in the best possible way, a good PO should attend refinement sessions armed with everything they need to answer questions and get across to the development team what it is the user needs.

For the dev teams, this stage involves all the ideation, research and thinking that goes on before the product is formulated into something they need to work on. But for a PO, this stage is likely to encompass the multiple processes they’ll go through to flesh out and identify something for the Product Backlog, such as user testing, user research, value mapping and so on.

The development team is probably the largest resource involved in the project, so their time should be treated as a valuable commodity. Good preparation is crucial to making subsequent stages run smoothly. An experienced development team will quickly find holes in poorly thought through backlog items if the PO has not done their homework – but a simple conversation can quickly solve this to move onto how to achieve the backlogged item. 

In cases where a PO needs some more time to prepare, it’s often beneficial to delay the refinement session, rather than working through or around any gaps in the session itself.

Some important things a PO should prepare for every story at this stage:

Diagrams

How it fits within the roadmap and what else is coming up

A clear description

Personas

Context

The following may be fleshed out or modified in later stages, but they should at least be initially outlined as the following:

Acceptance Criteria

Error and Edge Cases

User Interface Designs

Stage 2: Engage the creators

Once the PO has a product backlog item ready from Stage 1, we have a combined session with the development team. The purpose of this session is for the PO to fully explain why the backlog item is important and what the expected outcome is. The development team uses this opportunity to ask questions and clarify the PO’s expectations.

It’s the PO’s responsibility in this stage to verify that the development team fully understands what’s being asked of them. To make sure the team understands what has been discussed, the PO employs active verification, where they ask one of the Development Team to explain the item back in their own words. This technique works particularly well when performed by a junior or newer member of the team, and often leads to further conversations around things we previously thought were understood.

Once the PO is happy that the team has fully understood the backlog item, refinement of the item can proceed to the next stage.

Stage 3: Refine the tech

At this point, the development team starts to think about the technical implementation and how they might approach each backlog item. Typically this will take place without the PO, but they can be present if they wish.

The amount of time a team spends breaking down the work can vary depending on the complexity of the project or experience within the team. We use techniques such as Story Pointing and Risk Sizing to help structure the conversation and indicate where we need to break something down further. Generally we will look to break riskier and larger stories down into tasks that should take no more than a day. We will also have members of QA sometimes lead these sessions to give focus to edge and error cases. 

As part of this stage, if appropriate, the team may create technical diagrams and schemas to break the work down further. Any dependencies the team identifies should be highlighted, especially if they’re needed before the work can be started. The team may also choose to consult technical expertise outside of the team.

When breaking down the work, the team sometimes finds there are a number of options for how they approach the work, these may come with compromises to the intended outcome or for how things might be developed down the line. In these cases the team consults with the PO and outlines what the impact is on the user, effort to complete, and any potential impact on work further down the line. Then, the PO can make a call on which option will be best for the product/business.

Once the team is satisfied they have a consensus on how they will undertake the work, we progress the item to the next stage.

Stage 4: Confirm and commit

The final stage involves the development team and PO getting back together and committing to do the work.

The PO once again reviews why the item is needed and what they’re expecting the outcome to be. The development team responds with their proposed solution, confirming the expected outcomes with the PO.

In a Scrum project, we’d usually undertake this final stage during the first part of sprint planning. If not operating in sprints, this stage takes place wherever it is that the team identifies and commits to the next set of priority items to be worked on.

Is it worth it?

One of the big concerns people often have with involving teams as extensively as this in product refinement is that it disproportionately takes time away from ‘coding’.

In our experience, when teams have adopted this more formalised approach to product refinement (especially for teams where they had to significantly increase the amount of time they were spending in product refinement), we’ve seen no negative affect on their capacity to deliver. 

One team in particular saw roughly a 20% increase in output from the team for every additional hour they spent during product refinement in the previous sprint, which ultimately results in a shorter time to market for the features being worked on.

Another area we’ve seen improvement is in a team’s ability to deliver exactly what is being asked for and on time. We’re finding that teams who are investing in the refinement process are seeing higher predictability and lower levels of re-work and defects.

Of course, it’s not all roses – something that shouldn’t be underestimated is the amount of effort required on behalf of the PO to feed the development team with well thought through plans. In cases where the role of the PO will be undertaken by a client, something we’re very keen to discuss is how much time they have available to dedicate to the team.

The impact of increasing or decreasing the focus on refinement may not always be felt straight away, especially for products that are not yet in the hands of users. 

At Apadmi, we now see the time spent in product refinement very much a long-term investment into the products we’re building, and one of the leading indicators to a project’s success.

If you’d like to find out more about how we help global brands and ambitious organisations innovate and grow by developing solutions that make things better, get in touch or head over to see our work.