Single backlog. Multiple teams. How to handle Backlog Refinement?

Question

Background

Hi all, I am an experienced SM but I thought I would crowdsource a solution to this from peers. The project is an enterprise scale migration to the cloud with over 500 customers representing 300+ applications.

The backlog is run by a single Product Owner (also a Cloud Technical Architect) who is supported by a BA.

• Three teams
• One backlog
• Each team has their own stand-ups, sprint planning and retrospectives
• We have a shared Review with customers

Question

When dealing with a single backlog which feeds multiple autonomous feature teams, what is the best way to approach Backlog Refinement or "Play Ready workshops" or [insert generic name for looking ahead activity]?

At present the BA invites all developers from all teams into a single Refinement session to start discussing stories in detail. The devs have, rightly, balked and 19 of the 21 devs just opened their laptops and started coding again.

They have requested an approach where the BA spends time understanding the story in detail through 1-2-1 sessions with devs and only bring those stories to the Refinement session to see if they are ready for Sprint Planning the next week. The BA has balked at this approach since it would be 3 Refinement sessions, also predicting which team takes which stories from the backlog etc.

The Product Owner is swamped conducting technical assessments/communications for the app migrations and has devolved story preparation to the BA's.

They are at an impasse and morale has dropped off a cliff. As the most experienced SM, the other SM's have handed this hospital pass to me to solve.

Out of scope

We have solved a lot of issues in this delivery including operational handover, definition of done etc so I don't want to rehash those.

Answer 1

I can see why the devs have balked, as the current approach doesn't sound constructive.

I also don't see an issue with their request as they are basically asking to refine the stories with the right team members or subsets of the overall dev group.

From a BA perspective, and having played the role myself, I do understand the challenges of holding multiple refinement meetings as well.

Two suggestions to offer++:

• Consider when you're holding the backlog grooming sessions. The BA is pushing back because the current setup probably doesn't allow for sufficient refinement time
• Treat the refinement as a continuous process; there shouldn't be a need to wait until the designated meeting time if there's something that could be straightened out earlier (this calls for working in conjunction with the scrum master, so interruptions to the current sprint are minimized)

++ The suggestions are from this article, see Options 3 and 4. http://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/

Answer 2

First of all, I will assume that this migration is the only project that any of the teams have to work on currently.

In order to maintain a Scrum mentality, you need to find "Epics" that can be dealt with in their entirety by a single Scrum team, and allocate the Epics evenly around the teams until the project has been delivered.

If there is absolutely no way that the migration stories can be split into "Epics", then the only reasonable option is to get all the teams working together from the same board with the same schedule. Otherwise you are going to drown the business in Sprint administration. I would drop Scrum and work from a Kanban board, with each developer picking off a task at a time until the project is done.

Of course, your business may not approve of dropping the Scrum methodology.

I also think you have not allocated enough BA resource to the project. One BA cannot support three Scrum teams at the same time, and the BA will become the limiting factor on the project. 1-2-1 sessions with the BA might suit the devs but will be even more time consuming than the single grooming session. There is no need for every dev to be in the grooming session, a couple of representatives from each team should be enough, who can them pass on their knowledge to the rest.

Answer 3

At present the BA invites all developers from all teams into a single Refinement session to start discussing stories in detail. The devs have, rightly, balked and 19 of the 21 devs just opened their laptops and started coding again.

If you have a couple of mid sized scrum teams, this may work. With larger teams, this becomes very tricky to manage, even by experienced scrum masters. I am assuming these meetings go on forever as well?

With that out of the way, I can recommend the following:

1. Let each team decide who will attend the refinement meetings from their team. This can and should change from time to time. This way, you will have fewer attendees and a far more focused meeting. Be wary of the teams nominating a newbie just to fill in the blank.
2. Make sure these meetings do not take more than 10% of the teams' time during the sprint
3. Get creative and make the meetings with many attendees fun (only in cases where most developers have to attend to provide feedback). Maybe use The Big Wall. This is used for estimation but I don't see why it cannot be used during refinements where for example you group dependent items together in different corners of the wall? This can increase participation. Remember, the main purposes of refinement meeting is to reduce cross-team dependency. You can group unclear/super-large issue into another corner so they can be refined.

Answer 4

Who Owns the Solutions?

In Scrum, the team owns the solution. You mention in the question that the PO is doing a lot of technical assessment. I expect that the BA is then doing some more as they prepare the backlog items. If the team is expecting to just receive ready-to-go solutions, then it should be no surprise that they don't see value in spending time in backlog refinement.

So first thing to solving the problem should be putting the solution back in the dev team's hands - let them to do the technical analysis and plan the migrations. The PO should be focused on the business value and prioritization of efforts.

So Back to Backlog Refinement

Once you do this, the whole conversation becomes much easier. I've worked on some cloud migration efforts before and they're usually fairly complex. Those teams are probably going to need to talk to each other - a lot. If they own the solution, I expect they'll do at least part of their backlog refinement together, then take some of their work back to their individual teams to refine further. LeSS provides one possible solution in this case (https://less.works/less/framework/product-backlog-refinement.html)

Answer 5

I assume company is in transformation process. Partially implemented Scrum but haven't delegated responisbilities and product knowledge to Scrum teams. What more this is obviously not possible immediately. This means we have developers who are able to handle technical tasks but they need BA to understand requirements.

What was already said here BA is bottle neck and one need more BAs. If we can't have more BAs maybe we can do something with 1on1 sessions. They are very efficient because we're not loosing time of multiple people but they are blocking knowledge sharing. BA has 1on1 sessions and this means later on grooming only that person knows what is story about. I'd recommend replacing 1on1s with small groups working on related issues to improve knowledge sharing. If each group has at least one person from each Scrum team it should improve understanding of functional requirements in teams. If teams have better understanding and know what they are working on they should be more engaged.