Backlog refinement anti patterns
I have reservations about how my team implements Agile Scrum, particularly with our backlog refinement process, which seems to deviate from established best practices. Currently, during the refinement meeting a product owner introduces a new initiative through an epic, it triggers the creation of a refinement task. This task covers everything from generating tickets and planning implementation to securing the necessary details or resources to ready the tickets for development. Responsibility for this task falls to a role we call the engineering lead—a position unique to our organization and distinct from a tech lead. The engineering lead's duties include refining tickets, planning, acting as the main point of contact, and ensuring timely completion of the project. However, this role works in isolation to perform the refinement task during the sprint, creating tickets and plans without input from the rest of the team. Although we hold two scheduled backlog refinement meetings within the sprint, if a refinement task is completed outside these sessions, the engineering lead proceeds to independently estimate and incorporate the task into the sprint, often completing projects without any team involvement. Typically, our backlog refinement meetings consist of product owners presenting an idea and assigning a refinement task, we don't do refinement in the meeting as the refinement ticket covers that. If an engineering lead has finished their refinement task and created tickets, we also take a brief moment to review and estimate those tickets during the meeting.
This method is concerning to me as it appears to encourage several Scrum anti-patterns. Assigning refinement tasks to individuals rather than conducting refinement during backlog refinement meetings with full team participation compromises the goal of creating a shared understanding. This practice not only delays incorporating team feedback into the implementation strategy until after the refinement phase but also leads to the formation of knowledge silos within the team. Moreover, delegating the responsibility for project delivery to specific engineering leads seems to clash with the Scrum principle of shared accountability in achieving sprint goals. Are our current backlog refinement practices consistent with Scrum principles?
If the work is well understood, perhaps an "engineering lead" actually can do the various things you mention, and be right about them. Yet if that was the case, you wouldn't need Scrum at all.
Scrum is for learning to build the right thing at the right time under complex conditions of high uncertainty. This requires a joint team effort. So, what are the consequences of the antipatterns you mention on on the team's ability to innovate, and to collaborate on achieving valuable outcomes each Sprint? If there is no actual pain-point, why not?
Some of the consequences I see coming from these anti patterns are the following:
- Reduced Team Flexibility - Isolated refinement leads to engineers specializing in narrow areas of work where other engineers on the team lack context, creating bottlenecks and difficulties in redistributing tasks when someone is absent.
- Missed Opportunities for Accelerated Development - Relying on one person's knowledge during refinement can slow down the process. For instance, Engineer A might waste time researching information that Engineer B or C already knows, whereas collaborative refinement could have quickly shared this knowledge.
- Limited Early Input - Refining tasks without team input limits the diversity of ideas and feedback until the code review phase. This can necessitate significant changes if the team's feedback requires a different approach, leading to avoidable rework.
You might see them coming, but have they resulted in any negative consequences right now, and are presenting a pain-point for others?
Every team I have worked with has done refinement differently. Some of them have shared some parts of the process but no two have been identical. That is because each team is made up of unique individuals and bringing a group of unique individuals together in a self-organizing team rarely results in identical practices. So, is the way your team does refinement "wrong"? Not if it works for them.
You seem to want all refinement to be done in "refinement meetings". One practice that many of the teams I have worked with shared was that "refinement meetings" was a last resort. Many of them had an agreement that everyone would spend X hours a week reviewing the Product Backlog and providing information that they had on various items. Many of them captured this in the item if the system allowed (for example, comments in a Jira ticket). A couple would create discussion threads in their chat system. Regardless of how they did it, many Product Backlog Items could be refined without ever having to meet as a group.
If @Ian hadn't posted his last response, I would have. Because, if there is not a problem occurring, as a Scrum Master, I would not worry about it. I might watch to see if problems arise but it isn't anything I'd mention to the team until issues started to arise.
Backlog refinement meetings is not a ceremony in Scrum but most teams do it as it helps make Scrum better (speeds up the sprint planning in most cases). The process you follow, if it yields the right results then probably it is not concerning. The responsibility of the backlog rests with the product owner and in your case the task of refinement has been delegated to the engineering lead which is fine. However, the engineering lead should not work in isolation and he should be working closely with the product owner. The developers will eventually come into the picture during the sprint planning and that is the meeting which you could closely observe as a Scrum master. Are there difference of opinion regarding understanding of the task and estimates? That should help you get a better understanding if the current way of backlog refinement is fine, or you need to make some changes into it.
In most cases the practice is as mentioned by Daniel, the team spends x hours a week reviewing the backlog. No matter who does it (or how it is done), the refinement is beneficial for the overall hygiene of the backlog.
It's clear from your post and the responses so far that there's a significant concern about the lack of collaborative involvement in your team's backlog refinement process. Echoing the potential for leveraging technology to enhance collaboration and transparency during the refinement process, tools like shared digital boards (e.g., Trello, Jira) or collaborative documents can facilitate asynchronous refinement activities, allowing the entire team to contribute insights, questions, and estimates even outside formal meetings. This approach encourages continuous refinement, enables the engineering lead to collect input from the team asynchronously, and supports the creation of a shared understanding of backlog items before they're formally discussed in refinement meetings. Additionally, implementing a rotating refinement facilitator role could democratize the process, allowing different team members to lead the refinement process periodically. This not only prevents knowledge silos but also fosters a deeper collective understanding of the project and encourages a more distributed sense of ownership and accountability, aligning more closely with Scrum principles of shared responsibility and team collaboration.