Product backlog refinement meetings are filled with opportunities for improvement.
I see more time wasted in refignment meetings than in all other meetings combined.
Understanding the purpose of backlog confinement is essential to comprehending why.
The purpose of refinement is to ensure that the items near the top of a product backlog can likely be completed in the upcoming iteration.
This means that items need to be small and sufficiently understood.
Small is straightforward.
A team cannot bring a large product-backlog item into an iteration and expect to finish it.
Most teams have a maximum size they allow into the iteration, I suggest no more than half of the team's velocity.
For instance, a team with a velocity of 20 could bring in an 8-point item into the iteration, but not a 13- point item.
I certainly prefer items smaller than a half a teams velocity, But half works as an occasional upper limit.
Sufficiently understood means that enough is known about an item to bring it into next iteration.
It does not mean that everything is understood about that item!
The goal in refinement meetings is not to eliminate all uncertainty, but to reduce it to a level where the team feels comfortable starting work on the items,
even if some issues remain unresolved.
Teams are encouraged to address some of those open issues during the iteration, as overlapping work and decision making are key aspects of being agile.
The team should resolve enough open issues so that they think an item can probably be completed within the iteration.
I want a team to feel like they probably know enough to complete the item without putting in so much work ahead of time that their sure of it.
They should finish refinement of an items thinking they've addressed all or most of the significant open issue and enough of small ones to feeling good
about the likelihood of completing it during the sprint.
There's a trade-off between spending more time answering questions before bringing the item into an iteration and just bringing it in and using the iteration
to identify open issues and resolve them.
It's often faster to bring the items in, and get started on it.
When a team attempts to resolve all open issues during refinement, the meeting lasts considerably longer.
Additionally, time is wasted as the entire team discusses each item, even when only three or four different people are required for each.
Being compelled to attend a meeting where much of the discussion is irrelevant to you certainly frustrates team members.
Let's look at three things you can do to keep backlog refinement meetings shorter, more productive, and less frustrating.
First, position the product backlog-refinement meeting as a pre-planning checkpoint.
Don't necessarily rename the meeting, but emphasize its function as preplan check.
The team reviews the top items to ensure they are ready for the iteration.
If items are not ready, they can be made smaller or have details added to them.
Second, emphasize that not all open issues need to be resolved in advance.
Backlog items need be sufficiently understood, not perfectly understood.
I like to do this by frequently asking, do we know enough about this item that we can probably finish it during the iteration?
This reinforces that a team should know ENOUGH, but not everything.
Third, consider having only a subset of the team participate in refinement meetings.
Generally, I'm in favor of full team involvement in activities.
But backlog refignment can be almost as effective with significantly less time spent when only subset team members are involved.
If the whole team participates, a certain number of questions will be asked to clarify what needs to be done for each backlog item.
Conducting the meeting with about two-thirds of the team usually generates nearly all of these same questions.
The participants can vary from iteration to iteration depending on who's available.
If someone consistently cannot attend, this should be addressed in a retrospective.
While refinement meetings are collaborative, flexibility in attendance ensures the team balances refignment with ongoing iteration commitments.