Skip to main content

planning poker is being influenced by implementation

Last post 06:26 pm March 7, 2013 by Sanjay Saini
6 replies
03:38 am March 5, 2013

I work for a small company and we have had 3 short sprints with considerable success but have been having trouble with the product backlog refinement meetings where we can get derailed on implementation concerns.

In the backlog refinement meeting we play planning poker but we often find ourselves in situations where people are giving different values based on potential implementations. An example would be one person choosing 8 when they think the task is best done using a database layer and another person choosing a 1 because they think hard coding would be sufficient. We attempt to debate the merits of each approach but in some cases it can never quite narrow the gap completely. This ends up derailing our backlog refinement meeting for 15 to 20 minutes each time and the product owner is completely unnecessary for this duration. It seems like it should be a discussion for the sprint planning meeting if not just an informal discussion during the sprint.

We have taken to effectively averaging the weightings but that seems to completely invalidate the entire weighting process.

How is this handled by others? Should we say that implementation is not to be discussed during backlog refinement and if so, how do we decide on the effort required? Should we continue to debate the implementation as it might better define the PBI and if so, where is the boundary between the product backlog refinement meeting the sprint planning meeting?


05:46 am March 5, 2013

Backlog refinement isn't a recognized Scrum event, although something like it is provided for in the Sprint Review. The Scrum guide says: "The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings".

More broadly though, I'd consider backlog refinement/grooming to be part of a team's ongoing responsibilities during a Sprint. And because it isn't a recognized event per se, the options are flexible..

If I was you, I'd consider handling this by not discussing implementation during backlog planning meetings, or providing estimates at that point. It would just be for understanding the requirements as expressed by the Product Owner. This should be done sufficiently in advance of the Sprint Review to allow the team time to mull over the technical options between themselves. They then have the Review to organize the backlog further in advance of Sprint Planning.


11:33 am March 5, 2013

I agree with Ian. Separate the grooming of the backlog (creation of acceptance criteria and fully understanding the backlog items) from estimation. You may also want to try the White Elephant method of estimating, rather than Planning Poker. I find that it's easier (and faster) to come to an estimate consensus this way.


02:30 pm March 5, 2013

When you say each team member thinks differently, it is genuinely or is there any personality conflict? I suggest you doing some team building exercise on trust building. This may sound a bit awkward but may work.


10:16 pm March 5, 2013

HI Kulin,

Its very natural to discuss implementation during this time -- I would allow the team to do so, otherwise, they may not have a good mechanism to give an estimate or comprehend what the PBI is requesting.
(Hint: Can the PBIs be split further, on the request of the Dev Team?)

I think what you're describing could be addressed by a Spike (from eXreme Programming). This is something our Dev Team use when there is an unknown or there are multiple approaches to a situation.

What we essentially do is to take a step back and estimate and timebox the Spike. Thereafter determine the path forward before taking on the product backlog item needed by the Product Owner.

There are other estimation techniques, but I think the issue isn't just estimation.

I would also encourage you to continue on the Product backlog grooming as anything done here will help by the time one reaches the Sprint Planning.


01:33 am March 7, 2013

I think Ian is right, grooming is to understand the requirement not the estimation phase. That should be done during next sprint planning meet. By then, team may think thru the best possible way to implement. I think we are combining grooming and sprint planning meeting. Moreover, grooming is just to have elaboration on the requirements nothing towards estimation or implementation technique.


06:26 pm March 7, 2013

I disagree, I think putting estimation is part of the grooming meeting. As a product manager I need a plan for next few sprints and until and unless you have estimation put into the PBIs you can't predict anything. Also you can't estimate a lot just in the planning meeting.


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.