Backlog Refinement - do all members of DT participate?

The whole development team doesn't have to attend Product Backlog refinement, but they are jointly responsible for the quality of input provided, including estimates. So arguably it is more a case that the whole team should attend, as a matter of good practice, in order to assure the quality of the outcome for which they are all accountable.

Thanks, Ian. It sounds reasonably.

What I observe is that Dev Team members who didn't participate in refinement workshop will have more difficulties to implement the PBI because they will lack a lot of information.
They will ask for the same information they should have obtain in the refinement workshop or they won't work on the item, resulting in a lost of swarming possibility.

Olivier,
I agree. On the other hand a person that doesn't feel like taking part in the Refinement might slow the rest of the DT down. By asking lots of clarifying questions, for example, or in any other way.

Definitely agree with the joined team responsibility.
In the past, I have worked with teams where the knowledge and skills are not interchangeable. Either the differences are too big or the team really don't want too.

In these situations, getting them all in a Refinement was seem too inefficient and not-productive as no dialogue was happening between the different disciplines. In the end we split up the refinment sessions.

I usually prefer PO/ BA working with only the relevant team members and SMEs for the initial work on the story before bringing it to the whole team as part of the regular PBR sessions. Any questions/ clarifications from the team are then followed up by the PO/ BA. The story is brought back as many times as required to the PBR session until its sufficiently understood by the team. This approach worked really well esp. with distributed teams as its balanced efficiency and the need for whole team involvement. Smaller and simpler stories were brought directly to the PBR session.

Posted By Ranjith Kumar Kilari on 16 May 2016 12:43 PM
I usually prefer PO/ BA working with only the relevant team members and SMEs for the initial work on the story before bringing it to the whole team as part of the regular PBR sessions. Any questions/ clarifications from the team are then followed up by the PO/ BA. The story is brought back as many times as required to the PBR session until its sufficiently understood by the team. This approach worked really well esp. with distributed teams as its balanced efficiency and the need for whole team involvement. Smaller and simpler stories were brought directly to the PBR session.

If the PO/BA works only with the relevant team member/SME on the stories, then why still having a PBR. Isn't it already refined if the BA/PO and SME sits together?

Good question. This is for the initial conversations with the users/ business to gain an understanding of what's being requested; with those stories where the po/ ba don't already have that understanding.

Pablo,

A major reason for having PBR's is to create a shared understanding between the team and the PO of upcoming work. That is not possible when a PO meets with a subset of the team (BA, SME) to initially begin story discussion and refinement.

With Agile/Scrum, we want to identify as many opportunities as possible to have conversations as opposed to working on something and then handing it off to someone else, or throwing something "over the wall". Granted, there are times when such dynamics are necessary, especially in starting out in Scrum, but we want to be aware of such practices and recognize them as "less than ideal".

A major reason for having PBR's is to create a shared understanding between the team and the PO of upcoming work. That is not possible when a PO meets with a subset of the team (BA, SME) to initially begin story discussion and refinement.

Fully agree, but as I mentioned, if you are in a team where the technology is so different, that the team is explictly saying that there is absolutely no use of creating a share understanding.

Posted By Pablo Rossi on 17 May 2016 12:45 PM
... as I mentioned, if you are in a team where the technology is so different, that the team is explicitly saying that there is absolutely no use of creating a share understanding.

It seems to me that you are describing a working dynamic that unfortunately does not resemble a team in a Scrum sense, Pablo.

If there is no shared understanding or shared ownership of accepted sprint work within a "team", that is a red flag to me. It indicates the team may not understand the negative aspects of specialization, or the benefits of team-based development both on productivity and quality.

It is up to the Scrum Master (or Agile Coach) to provide such direction and insight in order to alleviate team ignorance, if that is the case.

Posted By Timothy Baffa on 17 May 2016 02:24 PM

Posted By Pablo Rossi on 17 May 2016 12:45 PM
... as I mentioned, if you are in a team where the technology is so different, that the team is explicitly saying that there is absolutely no use of creating a share understanding.

It seems to me that you are describing a working dynamic that unfortunately does not resemble a team in a Scrum sense, Pablo.

If there is no shared understanding or shared ownership of accepted sprint work within a "team", that is a red flag to me. It indicates the team may not understand the negative aspects of specialization, or the benefits of team-based development both on productivity and quality.

It is up to the Scrum Master (or Agile Coach) to provide such direction and insight in order to alleviate team ignorance, if that is the case.

It is partially about team dynamics. They are fully aware of the collaboration that is needed, shared ownership and collectively working towards a sprint goal. Remarkably most of the stories they forecast gets done according to the teams DoD. Unfortunately the technology stack is so different, that it is (within this company) impossible and inefficient for them to do the refinement together. Even helping each other out is not possible. As a team they also prefer doing the refinement separately as it add no value but only waste.

What would you do? Coach the team in the value of teamwork, shared understanding, ownership, generalist vs. specialist etc. while you know it's organisational not possible

Pablo,

Without knowing any of the specifics, my suspicion is that the stories being groomed and offered to the team are solution-based or technical in nature, and reinforce the "technology stack".

That is where I would look first, to ensure that stories being created, groomed, and offered meet INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Especially "Independent".

If any story the team works on doesn't provide business or customer value in and of itself, and relies on other "components" (stories) to realize a solution to a business problem or needed benefit, you then have insight into your impediment. It isn't that the desired organizational change isn't possible, it is just made extremely difficult (and unlikely) by the way the organization (and the team) view work. That is a solvable issue, although it may take some time.

But again, this is just my guess based on the limited information provided.

Without knowing any of the specifics, my suspicion is that the stories being groomed and offered to the team are solution-based or technical in nature, and reinforce the "technology stack".

Yes and no. Most stories are functional in nature yet it adds value to the customer. Because of this we split up our Refinement sessions in the different technology stacks.

That is where I would look first, to ensure that stories being created, groomed, and offered meet INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Especially "Independent".

We have a DoR where the INVEST is a part of.

Thanks for the discussion!

On the other hand a person that doesn't feel like taking part in the Refinement might slow the rest of the DT down.

Good point which is why the SM has to keep everyone on track. According to the Scrum Guide on page 13, fifth paragraph, it states: "The Scrum Team decides how and when refinement is done.Refinement usually consumes no more than 10% of the capacity of the Development Team."

Therefore, the PB refinement meeting should be timeboxed accordingly to the duration of the Sprint. For example, if it's a 2-week Sprint then the meeting should be allocated a maximum of one work day. Excessively exceeding this limit will be negative and ideally the PB refinement meeting should take less time which each successive Sprint.

Posted By Doug Purcell on 19 May 2016 02:27 AM

On the other hand a person that doesn't feel like taking part in the Refinement might slow the rest of the DT down.

Good point which is why the SM has to keep everyone on track. According to the Scrum Guide on page 13, fifth paragraph, it states: "The Scrum Team decides how and when refinement is done.Refinement usually consumes no more than 10% of the capacity of the Development Team."

Therefore, the PB refinement meeting should be timeboxed accordingly to the duration of the Sprint. For example, if it's a 2-week Sprint then the meeting should be allocated a maximum of one work day. Excessively exceeding this limit will be negative and ideally the PB refinement meeting should take less time which each successive Sprint.

The Scrum guide is written from an ideal situation as in the entire team needs to participate. As mentioned above, this is of course far from reality.

Do you try to fit your organisation into scrum (which won't be easy, and if it is not easy what to do in the time being) or do you compensate (not entirely of course) but tailor some things while keeping it workable.

My original question was actually answered by Ian, but it's nice to see a fruitful discussion around the topic.

I personally like when people act according to what they personally want and value. That helps me as a coach to understand the current situation. Therefore when people have freedom to decide whether they participate in Backlog Refinement I can diagnose if that's the behaviour of well performing team. If, for example, in a team of 6 people there are always minimum 3 interested in refinement, thats probably fine, but I would observe:
- if it's not the same people all the time,
- if people with skills necessary to have fruitful discussion attend,
- if there are Refinement meetings when everyone is present.

The software domain and technology is an important factor here, of course, as well as some other factors, so above numbers are not fixed.
I would start to worry if people would pass on planning meetings, though, as I would expect all team members to participate.