Product Backlog refinement

The whole of the Development Team are accountable for the quality of Product Backlog refinement, including estimates made.

What do you think the risks and consequences would therefore be, if only some team members attend refinement sessions?

Let me to be more precise.

The refinement I was thinking about was only for getting more detailed information about some items in the Product Backlog Item.

Some risks:

* Scrum Team loses some Developers Team's opinions.

Mitigation: The Developers who attend to the meeting were choosed by the team. So, they represent the team and are valid members.

* After the meeting, a few Develpers have a better knowledge about this refinement.

Mitigation: The Develpment Team can have inner meetings to comunicate information about the refinement when it can be neccesary (Self-organizing).


* (High Risk) If the refinement was done about a Product Backlog Item placed on the top in the Product Backlog and some very important information was added to it, only some Develpers can work on it eventualy in the current Sprint, if the item is added, or in the next Sprint (Product Backlog Item selected)

Mitigation: In this case, the whole Team must attend this meeting.


* (Very Low Risk) The refinement is done on items placed low in the Product Backlog.

Mitigation: Inner meetings. Self-organizing


The advantage I see is that the more refinement meetings we have the more information emerge and a more precise picture the Scrum Team have.

But we don't need a very precise picture about the items placed on the bootom of our Product Backlog, do we?

Given that the disengagement of team members from team activities will incur risk, it would be best to question why they would incur that risk in the first place. What problem are they trying to solve by not attending and how did it arise?

I was not thinking in a scene in which some people were having problems. Rather the complete opposite, a very good Sprint in which some people might be free (only some hours).

And that people might have a small refinement meeting. May be to verify there are not anything forgotten with the next Product Backlog Items or to get more detailed info with Product Backlog Items down in the list.

Are there better options to spend these hours?

If it has been a very good sprint, which suggests that the Sprint Goal has been achieved ahead of time, why would only *some* of the Development Team members be free?

The Sprint Goal is achieved with all the Sprint Backlog Items finished.

But we can imagine some Sprint Backlog Items finished and a few items in progress with enought people working on them and no risk. So, there are some Team members busy.

Are you suggesting that free people should move to the Spring Backlog Items in progress? or may be to add a new Product Backlog Item to the Sprint with no time to finish it?

In the first option I think people moving to the items in progress couldn't have enoguht time to do something. And may be they might annoy people finishing the work.

In the second option, take new work (from Product Backlog) that you know you can't finish is not very motivator..

Do you think first and second options are a better choice?

Some other option?

Thank you in advance.

> Are you suggesting that free people should
> move to the Spring Backlog Items in progress?

That's correct. Development team members should go to where the work is, because they have work to do as long as the increment remains undone. If they can't help their fellows to finish the increment then teamwork needs improving.

Once the increment meets the Definition of Done, the team will be free.

Back to the original question:

I think it very much depends on where you draw the line between refinement and planning.
In my eyes, it is absolutely essential, that the whole team knows exactly what needs to be done for PBIs drawn into the sprint, and they should hear it directly from the PO rather than a filtered version! Also the whole team needs to estimate the PBIs.
If you do this during the planning, and refinement work includes only making the Product Owner aware of additional (technical) details and discussing new features or ideas (low in the backlog), it might be absolutely fine, to have only some team members on board.
Or you might have different refinement steps as well indeed. A more official one, where you make sure a Definition of Ready is met and where you estimate the PBIs.
And then a more ‘early stage PBI’ one where you have general discussions on new ideas. Where you might on one hand say, the input of all team members is very valuable, and I want them all to participate. Or on the other hand, there would be too many discussions and it would take too much time, if all team members are on board.

I think this is exactly the reason, why the Scrum Guide does not define a refinement meeting but only states, refinement is an ongoing process and “The Scrum Team decides how and when refinement is done”.

Another thread on this subject https://www.scrum.org/Forums/aft/2016#10727

Nice discussion guys, I'm complete in agreeing with Ian in all his points of view. Maybe David you can continues with your idea and sum all hours and get a day of work at month so your goal of creating a high performance team will be achieved, without tailoring scrum so the real benefits are lack.

Best,
Gabriel

How are the refinement events conducted? I have experienced success with multiple levels of refinement events as it sounds like Sebastian was discussing.

The senior level DT members can do a cursory evaluation of the Product Backlog to ensure basic understanding of the items. They can then meet with the PO for any necessary clarifications.

All of the DT members and the PO can have a more formal event to ensure "Product Backlog items that can be 'Done' by the Development Team within one Sprint are deemed 'Ready' for selection in a Sprint Planning."

Both of these occur outside of the Sprint Planning event in order to allow that time box to be utilized for focusing on the new Sprint's commitment.

I feel that this is a great example of the importance of self-organizing and the beauty of the Scrum framework.

I feel there is not an only one good answer for this question.

Thanks everyone for sharing your experience.