I’ve been working with a scrum team for the last few months, and the team is storming (1) on ‘how we do refinement’.
Here’s what the scrum guide says about refinement:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. (2)
This scrum team works on a combination of production support issues and a backlog of product updates. The product is a mature, complex web application with UI flows, calculation engines, and multiple external system integrations. So, it’s a complex technical environment, nothing new there.
The main focus of this team is to work on a backlog of small to medium sized features. The team works on many features at a time, so there are generally pairs or threes in the team working on delivering these features, inside a single sprint.
However, this scrum team also has Service Level Agreements with a high profile external client, which means we need to respond quickly and frequently to unplanned tasks. In addition, this sometimes means we use refinement sessions to plan new issues that are either urgent, or important… or both (the doomsday scenario!) (3)
In addition, the team also responds to requests from internal stakeholders, and these are requests for features or enhancements from other departments inside the organisation.
The development team is quite large: 7 Dev, 4 QA, PO, SM.
Across the organisation, there is a prevailing culture that refinement should happen during a meeting in the sprint, with the whole team attending.
However, our team have requested that we manage this time better, so that they can avoid unnecessary meetings where possible, and remain more focused on Sprint tasks. This seems like a totally reasonable request to me, so we have been trying to modify how we do refinement in recent sprints.
What we’ve tried so far
I’ve been working with the team’s Product Owner, and we have tried to prepare an agenda for upcoming refinement sessions.
That is, we list out the next product backlog items that the PO would like to refine, and publish it to the team as early as possible before refinement.
Then, we book a session in a meeting room, and make a rough attempt to time-box the session. The main goal is to try not to include too much.
Our intention is to show this to the team in advance of refinement, to allow time to review and prepare, but also to allow team members to manage their time, and, for example, avoid refinement sessions that are irrelevant.
There are trade-offs here, naturally. I would love the team to be sitting together happily, and sharing knowledge about problem resolutions with each other, but their reality is different from that.
Boiling it down to questions
With all this in mind, I have a few questions I’d love to get some input on:
- As a scrum master or product owner, how do you ‘do refinement’ in the teams you work with? Is it a meeting with the whole team invited, or is it multiple breakout sessions? Should I challenge the team to attend together, despite their frequent complaints about refinement swallowing time?
- Also, from the context I’ve described, am I missing something that could be the real problem here? Are our problems with refinement a symptom rather than a problem? Even as I write this I am looking at things like the size of the team, the combination of planned and unplanned work…
What do you think?
References / Links
(2) The Scrum Guide