Backlog refinement

Hi Franck,
why do you want a part of the development team do the refinement and estimation? Is it because they specialize in the particular technology needed for those PBIs?
The idea is that you take advantage of the cross-functional team, spread scarce skills and each team member is committed to the estimation.
If only a part of the team is involved, you loose a part of this advantage.
For the second question: If you do not know yet which team will plan a particular PBI, and you do not want to do refinement and estimation with two teams, you should at least have a common set of reference stories. Inspect and adapt: If the team is comfortable with the estimation of the other team, then it is possible.
Best, Ludwig

> is it possible that one team do the refinement and estimation of a few PBI’s
> and that the other team put these PBI’s on their Sprint Backlog?

The best qualified team should do the estimates, and in an agile way of working there are none better qualified than those who will actually do the work.

Sometimes tentative estimates have to be given for an incipient project with a candidate Product Backlog, where it is unclear which team will actually end up doing the work. If the backlog is left unsized it will not be well formed, since each item in it must be given an estimate. Who will do this estimation though?

The answer remains the same: the best qualified team should do it. In other words, the team that is most familiar with the problem domain and/or technologies involved should relatively size the backlog, and preferably refine it further. This will allow the Product Owner to order the items in advance of any team being assigned. Of course, should a different team be given the work, they will then need to estimate the backlog for themselves.

> If you do not know yet which team will plan a particular PBI, and you do not
> want to do refinement and estimation with two teams, you should at least have
> a common set of reference stories

This is a perfectly sensible option in the scenario Franck describes, where multiple teams share one Product Backlog. Unfortunately though it is prone to abuse, in that reference stories are sometimes applied to teams working on *different* Product Backlogs. In my experience, this can be a shady trick by command-and-control managers to commoditize story points for team comparison, and/or to make unreasonable predictions regarding stage-gated schedules. Estimation then no longer serves the team's purpose of incremental delivery.

In my experience, this can be a shady trick by command-and-control managers to commoditize story points for team comparison, and/or to make unreasonable predictions regarding stage-gated schedules.

Hi Ian,
I understand that this might become a problem. How would you solve this and get estimates for a Product Backlog on which two teams are working? Which one is the best qualified team? Would you track for each estimation, which team has done it, and if the other team develops the PBI, you would get a second estimate?

> How would you solve this and get estimates for a Product Backlog on which two teams are working?

The problem I'm referring to doesn't apply to multiple teams if they are working on the *same* backlog. In that situation, the estimates will relate to a single product, and it is therefore perfectly reasonable for the Product Owner - or any other stakeholder - to expect the backlog to be consistently sized. To achieve this, teams can combine their estimation sessions or use reference stories, exactly as you suggest. The books by Larman and Vodde give excellent further advice in this regard.

That said, it is of course possible for meddlesome managers to try and compare teams, even if they are working on the same product. The best response is to seek the PO's guidance on whether or not sufficient value is being delivered sprint by sprint, and to keep the control of the associated process within each Scrum Team. Remember that good PO's won't care about story points or comparing teams...they'll care about receiving actual value in the form of potentially releasable increments. It's important for a Scrum Master to put the organizational focus squarely on delivery, and away from the commoditization of any proxy measures, as this is a crucial part of enterprise agile adoption.

> Which one is the best qualified team?

In the situation I described, an unsized candidate Product Backlog will exist for which no team has yet been assigned. The best team for estimating it can actually be made up on-the-fly, by selecting people from a mix of teams who know the domain and the technologies best. These may not be the people who will form the team that will do the work, but they should be the ones in the best position to relatively size the stories and refine them further. That's the purpose of the exercise...it gives the Product Owner a backlog of the best quality currently attainable.

> Would you track for each estimation, which team has done it, and if the other team
> develops the PBI, you would get a second estimate?

I wouldn't track which team has done the initial estimation. There's no value in that information. The important thing is that the best people available gave their estimates and that's all anyone should care about.

If a different team go on to develop the PBI's then yes, they would need to re-estimate the backlog because they are the ones who will be doing the work.

Thanks for the replies; it helps to implement Scrum in our organization.