A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum – More details about the Planning Poker process

The previous post (link) gave a brief introduction about what Planning Poker is, and what is the relevance to Scrum. This post has a bit more detail on the same subject, including conditions in which the Planning Poker is used, some of the related terms, and so on.
The Planning Poker needs to happen as a part of the Sprint Planning, after you and the team have had a chance to go through the various queries on breaking down the features into tasks, as well as deriving the Sprint Backlog from the features contained in the Product Backlog. The Sprint Planning has a defined time-period, and the use of Planning Poker to generate estimates has a defined time period that is part of the overall Sprint Planning meeting. You need to ensure that the team sticks to these time lines, and does not go very detailed discussions about these estimates, whether the estimate entered by somebody is right or wrong.
Also, since the Planning Poker is a part about the effort estimation process, make sure that the Product Owner is there, and if not, then set the discussion to happen at a time when the Product Owner is there.
Make sure that you have researched the process before proceeding on this one (including using the Fibonacci scheme to generate the alternate feature estimates – the Fibonacci scheme is one where the previous two numbers when added together, make the next number, the sequence goes like this – 0, 1, 1, 2, 3, 5, 8, 13, 21 etc).
Set rules for how the Planning Poker process should operate. If external stakeholders start interfering with the estimate selection process, then we have a problem on hands in terms of not letting the team be empowered to be able to estimate, and they will start getting accurate over these results as we do the review sessions.
Set rules for which estimates will be selected. So, if you consider the Fibonacci sequence above, people may be able to estimate for other 5,8 or 13 hours for most tasks. So, since you have a shortage of time, and you consider the first reaction of the team for providing these estimates as a good relation to their gut feel, you should specify which of these estimates should be considered. If somebody put a 5, and somebody did a 8, you should be able to set policies in the beginning about which one of them would automatically be selected. And the fact that people are expected to not know what the other persons are predicting in terms of effort numbers is actually a plus, and it is only when the different people open their cards do they get to know what other people are projecting in terms of effort.
Why do you need to be more strict in such kinds of estimation, and the time periods required by which this meeting would conclude.
The first estimates that a person prepares is typically a fair idea of estimate, and one should ensure that a lot of time is not spent on verifying and cross-resolving the individual estimates, just make a rule about which one to use, and go ahead.

2 comments to Scrum – More details about the Planning Poker process

  • […] previous posts (Details about Planning Poker process), I have explained the process of Planning Poker as a part of how to do estimation of tasks during […]

  • Generally a team will converge on an estimate. If all provide the same estimate, move to the next story without discussion. If numbers are not the same, have the high tell why it is hard, the low tell why it is easy and play a new card. This usually leads to better understanding of the story or of how to implement the story. If you cannot converge, maybe put the story aside for discussion later.

    I suggest not getting hung up on the rules and do something that keeps the process moving.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>