A question on backlog-refinement

Last post 03:45 pm September 11, 2019
by John Varela
7 replies
Author
Messages
08:59 am September 8, 2019

In our company we're half a dozen developers in our scrum team, and over the years we've made a number of products for our customers. Until recently we've been working towards everyone in our team have a familiarity with each of our products. We've worked in rotations, switching between who were to work on which solution now, using pair programming and shadowing alongside the person who'd previously worked on it. This was to lower the risk of unfinished projects, in case someone got sick or left the company. What we experienced though was a lot time spend trying to recall how things worked, when being back on a project you hadn't worked on for a longer period. Today we're working with 2 to 3 people being delegated to each product, and it seems to work better for us.

Now for the actual question:
During backlog refinement, should everyone in the team still participate in the meeting, even if the tasks doesn't involve the products they're assigned too? Backlog refinement tends to more often than not, take the form of some team members passively sitting around while those delegated to the project discusses.

I haven't been able to find some documentation on how to manage this sadly.

04:27 am September 9, 2019

Today we're working with 2 to 3 people being delegated to each product, and it seems to work better for us.

How many teams do you believe you have?

06:15 am September 9, 2019

Feels like 2 teams at most backlog refinements, sir.

06:32 am September 9, 2019

What kind of feedback is your team giving you about the meeting? 

06:30 pm September 9, 2019

I agree with Nils - talk to members of the teams, either individually or in a Sprint Retrospective, especially those you're seeing as passively sitting around. Ask them what value they're getting out of the meeting, if any.

Ask if it could be more valuable. Most of the time when I have these conversations with my teams, they will start to self-identify as not needing to be at the meeting, or they'll have ideas for how the meetings could be of more value to them and the team.

07:48 pm September 9, 2019

During backlog refinement, should everyone in the team still participate in the meeting, even if the tasks doesn't involve the products they're assigned too? Backlog refinement tends to more often than not, take the form of some team members passively sitting around while those delegated to the project discusses.

The answer depends -- on what works. In short, if you optimize in one area, you are generally de-optimizing another area.

  • Generally everyone on the Scrum Team should participate in the Product Backlog Refinement to ensure everyone is aligned to the Vision and Goals. This will reduce anyone needing to be "caught up" (optimize) but will increase the meeting cost and potential for too many people in the room and ineffectiveness (de-optimization).
  • However, when you are scaling with Scrum, it is often difficult and less effective to have all teams participate in the Product Backlog Refinement. It may be a compromise to have representatives of the teams attend (optimize) but they would have to catch their respective teams up (de-optimize).

Going further, it sounds possible that the symptom you mentioned of people sitting passively around may be indicative of a problem which I cannot diagnose without context/observation of your organizational and team design.

06:36 am September 10, 2019

Thank you all for your feedback - I appreciate the helpfulness.

I've gonna start a dialogue about it on our teamday, and hopefully that helps.

Also, I've found this article: https://www.scrum.org/resources/blog/myth-14-refinement-required-meeting-entire-scrum-team mentioning something called diverge/converge pattern I'm gonna try out.

03:45 pm September 11, 2019

To add a thought onto Mike's, participation requirements don't have to be defined by who did/does the work. Often just having common understanding on the solution decisions made is often the starting achievement.

That way when someone is a little out of the loop, they should be asking a question or two based on their understanding of the intention, thus sparking a conversation that brings alignment towards the next bits of work.