The Situation

When I joined a new product team as a Product Owner, it became apparent that our refinement sessions were significantly inefficient. Here’s an overview of what I encountered:

  • Multiple refinement sessions of around an hour each week.
  • On average, only one story was refined per session, with some sessions refining no stories at all.
  • Stories were sized using T-shirt sizes (extra-small, small, medium, large, extra-large), with many stories ending up as extra-large.
  • It could take weeks to refine a full epic.
  • The energy during these sessions was very low, with many unhappy faces.

These issues indicated that the refinement process needed substantial improvement. Fortunately, the team had a trusting environment with effective retrospectives, allowing me to share my observations easily. Based on these discussions, I received an action point and commitment from the team to start improving the refinement process.

The Improvements

1. Create Ownership per Story

A key step in increasing efficiency was assigning a responsible developer to each story to prepare it for the refinement sessions. This developer would determine if additional help was needed for preparation. The preparation of a story should take a maximum of 2 hours. If more time was needed, an investigation story, also known as a “spike” in the development world, should be created.

During refinement, we only discussed stories that were properly prepared and contained the necessary technical details. This approach significantly reduced lengthy discussions and increased efficiency, allowing us to refine an average of 10 stories per hour—a tenfold increase.

2. Not Accepting Extra-Large Stories

The team used T-shirt sizes instead of story points, with Extra-Large (XL) stories indicating significant unpredictability in time and effort. We decided not to accept XL stories anymore. If a story was deemed XL, it was broken down into smaller, more manageable stories, with a maximum size of Large. This approach made the refined stories clearer and helped increase the team's development speed (velocity).

3. Only Refine Stories to Be Picked Up Within One Month

Refining stories too far in advance often led to forgotten contexts and changes in technical requirements. We decided to only refine stories that would be picked up within one month. This approach ensured that the context remained fresh and relevant.

4. Increasing the Efficiency of Epics

The previous steps significantly improved story preparation, but I also saw room for improving epic refinement. Previously, business analysts wrote the epic stories, which didn’t always align well with development needs. I ensured clear descriptions of the problem and expected outcomes were created by the business analysts, along with detailed UX mock-ups for front-end solutions.

I then assigned a small team of two developers to prepare the epic stories. They could discuss any questions with the business analysts and decide on the general technical direction before creating the stories. During refinement, I introduced the epic from a business perspective, and the developers discussed the technical direction and detailed stories. This approach allowed us to refine a full epic in just two refinement sessions, with stories well-prepared and logically ordered.

The Refinement Process Checklist

Based on the above, I created a checklist for both the preparation and refinement ritual:

Refinement Preparation

  • A story only needs to be refined if the team is expected to work on it within a month.
  • The story is assigned to a developer.
  • Preparing a story should be done in 1 or 2 hours. If more time is needed, it should be an “investigation” or “spike” story.
  • The story has been discussed with the main business stakeholder to ensure the story is as clear as possible with the latest information.
  • The story is written to be understandable for everyone (not just a PO or developer).
  • Proposed implementation notes have been added to the story (and if needed discussed with other developers).
  • The status of the story on the board is changed to “Ready for Refinement.”
  • The main (business) stakeholder of the story has been invited to the upcoming refinement session (only if needed).

Refinement Ritual

  • The team agrees that the story is prepared enough to have a meaningful discussion.
  • The team has a discussion about the story.
  • The team agrees on implementation notes for the story.
  • The size of the story is estimated. If the size was estimated to be XL, the story will need to be split up and further refinement preparation is needed.
Ticket preparation requirements for bugs and features, grouped into Always, Bare minimum, Nice to have and Going for gold. A text version follows.
Ticket preparation checklist · Open full-size image
Read the image as text

Bug / incident

Always
Title; application(s) involved.
Bare minimum
Environment(s); screenshot including URL; report with steps to reproduce, expected result and actual result.
Nice to have
Test data.
Going for gold
Browser; operating system; first occurrence; screencast.

New feature or refinement of existing feature

Always
Title; application(s) involved.
Bare minimum
Goal; business value; user journey or data flow, including starting point(s), end point(s), and happy and unhappy flows in between.
Nice to have
Wire frame; test data.
Going for gold
Graphic design; explicit user expectations.

Conclusion

Implementing these improvements led to a tenfold increase in refinement efficiency. Additionally, there were qualitative benefits: a greater sense of ownership within the team and a noticeable shift from grumpy, pained faces to smiles. A happy team is indeed a productive team.

These changes didn’t happen overnight; they required persistence and gradual adoption by the entire product team. However, the effort was well worth it, leading to a more effective and enjoyable refinement process.

By focusing on clear ownership, manageable story sizes, timely refinements, and efficient epic preparation, product owners can significantly enhance their team's productivity and morale. This case study demonstrates that with the right approach and commitment, even the most challenging refinement processes can be transformed into a streamlined, productive practice.

Back to journal