Skip to main content

Backlog Refinement - do all members of DT participate?

Last post 06:38 am May 20, 2016 by Bartek Kobylecki
17 replies
07:54 am May 14, 2016

Scrum Guide says:
"[Refinement] is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items."

Charles Bradley in the tip #16 suggests that whole DT should take part in it http://www.scrumcrazy.com/Tips+for+Effective+Backlog+Grooming

I'm not sure if it means that SG requires all team members to participate?

If the answer is "yes" then here's the case.
I'm reading User Story Mapping by Jeff Patton. He recommends to have a "lunch-size" team do work on user stories, that is 3-4 people. If the team is 7, that creates a conflict.

There is more. Refinement is a creative process. Not everyone must be creative in the same time. Once someone is aware of his low level of creativity at the moment, why force her to attend?


09:40 am May 14, 2016

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.


09:58 am May 14, 2016

Thanks, Ian. It sounds reasonably.


10:48 am May 14, 2016

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.


10:57 am May 14, 2016

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.


Anonymous
03:41 am May 16, 2016

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.


12:43 pm May 16, 2016

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.


Anonymous
05:22 pm May 16, 2016


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?


05:43 pm May 16, 2016

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.


10:06 am May 17, 2016

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".


Anonymous
12:45 pm May 17, 2016


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.


02:24 pm May 17, 2016


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.


Anonymous
04:04 pm May 17, 2016


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


04:56 pm May 17, 2016

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.


Anonymous
02:14 am May 18, 2016


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!


02:27 am May 19, 2016

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.


Anonymous
01:56 am May 20, 2016


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.


06:38 am May 20, 2016

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.