Unable to backlog refinement (BR) meeting effectively
Hi All,
2-week sprint
BR meeting happens once/week.
My team is unable to do a BR meeting effectively. Usually, the changes we pick are part of a BIG feature, so when this BG feature first comes into the meeting, the team understands the overview to understand how the feature will work end to end. So this is what happens:
1st grooming: PO explains the feature, the what/why, etc, few questions come up from the team, etc. fully understood the requirement? NO
2nd grooming: Some questions from the team comes up. ( Another pain area: to come up with questions in the 2nd grooming, the team takes out the time between the 1st and 2nd grooming and sit together to brainstorm internally. They say they invest time to analyze the stories, etc, which is time consuming).in this meeting, PO expects the team to provide a road map/vision of how this big piece will be formulated. He has created 1 BIG story that contains all the info. In our project, the further breakage is what we expect from the team.
3rd grooming: Unable to provide breakage. Team says they cant until unless they get clarity on the question all. Please note 3 weeks have gone by with no estimates nor the vision provided by the tea.
Note: My PO writes the bug piece he wants. Like he wants to automate a process which the team has been using on excel. He is dependent on my dev team to tell him how this automation needs to be broken down.
How to improve. My PO basic complain is that weeks go by they neither get story pointers or t-shirt size estimates and since the breakage is given by team which doesn't come either, they don't have a healthy background. Please suggest.
Two things stand out, for me.
The first is the amount of time that is being spent on refinement. How big is your team and how many hours are being spent on refinement? The Scrum Guide suggests that refinement should take about 10% of a Development Team's capacity. For a very simple estimate, I would expect that a Development Team of 4 people working a traditional 40 hour week would spend about 16/hours per week doing refinement. How those 16 hours break down varies by team. I've seen where teams do most of their refinement collaboratively and other cases where individuals or pairs refine individual items and synchronize on a regular basis. Different things work for different teams.
The second is the method of refinement, and this partially goes with my first point as well. Not all refinement needs to happen in a meeting with the Product Owner. It may be useful for the Development Team and the Product Owner to synchronize on a regular basis, but there's plenty of discussions to be had or ideas to be discussed among the Development Team before meeting with the Product Owner. This can make the synchronization times between the team and the Product Owner more effective.
Story points and t-shirt sizes are irrelevant, unless you are required by management to include them so that they can run reports on performance or productivity.
The key is to ask the Development Team, how much work they can do in the sprint. Can you make the sprint shorter? Personally, I have found more success with one week sprints because team members can usually tell you on a Monday morning what they'll get done by Friday CoB.
You can try coaching individual team members in one on ones if you have the experience and the skills to be an effective coach (very different from an "Agile Coach").
Worst case scenario, you may need to take this to management because business agility needs to happen from the top down and workers needs to understand that participating in an efficient business process, which will improve the organization, is what they're getting paid to do. It's not optional.