Product backlog refinement didn’t use to be an official part of Scrum, but recently it was added as an ‘activity’ into the Scrum framework because many teams found it to be a useful practice.
Recently, the AMC discussed:
How does your team prepare product backlog items?
One of the agile coaches in the community, who works with 144 Scrum teams (wowza!), claimed there isn’t a single ‘correct’ approach to product backlog refinement. Some teams in his company hold a single meeting during the sprint to look ahead at the next sprint. Other teams conduct a shorter meeting each week of the sprint.
Whatever the meeting frequency, this agile coach said the outcomes are similar: * The next Sprint Planning meeting is much shorter. * The ‘uh-oh’ and ‘aha’ moments are discovered before the sprint starts.
The ‘uh-oh’ and ‘aha’ moments are when someone realizes they forgot an important consideration. If they wait until sprint planning for these discoveries, the team’s already working on committed stories and loses momentum.
Another member added that meeting frequency depends on the project size, team maturity and backlog health. His company keeps the product backlog refinement meeting at one-to-two hours. To build on the rhythm of Scrum, the sessions are pre-scheduled and are always held at the same place, same day, and same time. If the team only needs 30 minutes, they leave after 30 minutes. If there aren’t any new stories, they use the time useful to conduct an assessment of the backlog.
A member from New Zealand said his team schedules two hours per sprint on the Friday morning before sprint planning.
Another member chimed in that his team refines the backlog for two hours on day seven of a two-week sprint.
Two hours seemed to be a common theme.
Mike Cohn added some funny commentary on meeting length.
“I’ve had a couple of prospective clients call and tell me, ‘We need help reducing our sprint planning meetings—they take a full week!’ They’d spend Monday hearing about product backlog items for the first time, people would research them on Tuesday and Wednesday, they’d get back together on Thursday for backlog refinement, and then on Friday they’d do a planning meeting. Shoot me if I were on a team where that was the norm. No wonder people who do that type of ‘agile’ think agile sucks. I think that sucks, too.”
Another member added that refinement meetings used to be slow and painful at his company, where the team only managed to get through two or three stories in two hours. They introduced a 30-minute, pre-refinement meeting to get an early look at stories and do some more digging before getting into estimation. This approach worked really well for them and now they discuss about eight stories at every refinement meeting.
What’s on the Agenda?
One member said his team uses product backlog refinement to make sure all the user stories are ordered by priority in the backlog. They have a Definition of Ready checklist to make sure user stories are appropriately detailed. If time permits, they begin a conversation about each user story.
Another member described a detailed 9-step agenda for product backlog refinement:
- Decide on features at a high level.
- Apply CRUD to each Feature (Create, Read, Update and Delete).
- Add any additional pieces we want the user to have for the feature.
- Plot on a story map, release plan or user journey.
- Estimate the feature at a high level.
- Select first stories we’re kicking off, add in acceptance criteria, call out risks and dependencies and call out questions to answer.
- Estimate based on known info.
- Assign risks and questions for follow-up.
- Move story priority for the feature based on risk and dependencies with other teams.
Despite how often the meeting is held and what’s on the agenda, most members agreed that product backlog refinement is beneficial to agile teams.
To be part of the conversation and to hear more comments from team members and leaders on product backlog refinement, join the Agile Mentors Community. Visit https://www.agilementors.com for more information on membership.