same story, two different points

Hi Kyrry,

I am assuming that you are referring to planning poker in this post, but if not please let me know so I can try to answer in a better way.

If the team is estimating using planning poker cards, and 2 parties differ, they will need to talk it out, taking turns sharing their reasoning until they can agree. All stories belongs to the whole team, so the team should consider that any team member could working on that story. The whole team should participate in this activity to get as many opinions as possible, and in the end get the best plan of action in place with their estimates.

Hope that helps!

When you play planning-poker, you can't assume which team members will actually work on it.
For me, planning-poker is more a tool to drive a conversation that an tool to create estimate.

3 and 5 are close estimate. Does it worth it to go further in the conversation ?
Around me, when team members hesitate between 2 close value (3-5 ; 5-8) they have actually almost the same level of understanding of the item and they pick the highest value.
That's accurate enough and it protects the team from too long planning poker session.

> The reason one is a 3 is because that developer has more experience. Let's say
> that the '3' developer will not be involved in the story does it then make it a 5?

The story might be estimated as an 8, which would allow for knowledge-sharing between the more and less experienced developers. If constraints are being placed around collaboration, such that a single Development Team fails to present a unified position on matters which concern that role, then that is the problem that needs to be addressed.

Remember that Product Backlog Refinement serves as an indicator of the team's readiness for Sprint Planning, and not just the readiness of the Product Backlog. It is reasonable to expect a healthy (and at times robust) debate during Refinement, but we should also expect members to reach a working and practicable consensus so the Development Team role can be fulfilled, and which improves the collaborative position. If members can't demonstrate that single-team behavior during Refinement, there is little chance of them collaborating effectively once a Sprint is underway.

Thanks for the replies guys. Some interesting views.

I guess my main objective is to find out if it is 'true' that the size of a story is dteremined by the most experienced voice in the development team.

I concur with the view that it could be an 8 due to knowledge sharing (and that makes sense).

Also within our team there will be members that take the lead and/or actually do the work/story as opposed to another member that will not be involved in that particular story.

Just in case people are confused we are actualling doing BAU in 2 week sprints (not Kanban). But our BAU work is mainly derived from a Chang Steering Group.

The estimate must be agreed to by the entire team. Certainly there can be differentiation in estimates based on skill and experience.

I have employed a "best practice" approach when the team is torn between two close estimates (i.e. - 3/5, or 5/8). I ask the team if anyone has an issue accepting the higher estimate. Almost always, in the interest of time, the team agrees to the higher estimate.

As Olivier stated, it is important to remember that these are "estimates" based on the current information at hand, and they are never intended to be perfect. Settle on the higher number, and move on.