Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
planning poker is being influenced by implementation
Last Post 07 Mar 2013 05:26 PM by Sanjay Saini. 6 Replies.
Most Recent First
You are not authorized to post a reply.
05 Mar 2013 02:38 AM
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 Mar 2013 04:46 AM
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.
05 Mar 2013 10:33 AM
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.
05 Mar 2013 01:30 PM
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.
05 Mar 2013 09:16 PM
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.
07 Mar 2013 12:33 AM
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.
07 Mar 2013 05:26 PM
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.
You are not authorized to post a reply.