What is Planning Poker and how is it used for Estimating in Agile Projects? The subject of Estimation triggers heated debates amongst many Agile Practitioners. There are those who say that Estimation Wastes Time and must be removed from Sprint Planning. There are also the advocates of task estimation. A few circumstances may be encountered where the removal of estimates is agreed:-.

• The Project is small and involves only one Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team).
• The Team has Worked together prior to and understand each other’s skills. The team have a good idea of their Velocity (the Work achieved in one Iteration or Sprint).
• The Customers are comfortable with Agile Development. They have seen several Agile Projects finished prior to the present one and have confidence in the team to deliver.

Planning Poker: Project Planning

Think about the following scenarios:-.

• Agile has only recently been adopted and the Stakeholders in the Company are only familiar with Traditional Project Planning.
• The Scrum Team is new and have never ever Worked together. They do not know anybody else’s experience and capabilities.
• This is a large Project with many Teams and Inter-dependencies.

Where a Project has multiple Teams, Team A could be reliant on Team B completing a specific Feature. This feature may be required in order for one or more Features in Team A’s to Work to be started. Team A for that reason requires to understand when Team B anticipate to have “Done” the Work. The completion of the User Story, affects Team A’s Sprint.

We are much more likely to observed the scenario above than the perfect circumstances that we initially described. However, when estimating we can make it enjoyable for the team by Gamifying it with a Technique like “Planning Poker”.

The Power of Planning Poker.

‘Planning Poker’ requires everyone in the Team to Estimate the Size and Complexity of a User Story. They do this by assigning it a number of Points (we will go over scoring techniques a little later). Each Team member has a deck of cards with a sequence of numbers. These cards can be utilized to show the Value they wish to offer to a specific Story. For example:
3, 3, 5, 5, 5, 5, 7.

The Team members who have picked 3 and 7 must quickly describe why they have picked those Values. The Team then selects their cards again, until consensus is reached, or the majority vote is accepted by all. This is not a long process and must take no more than a few minutes per Story.

One of the Benefits of Planning Poker is that it is a great Team-Building Exercise. Everyone gets involved and Communicates why they made a certain choice. This tells the rest of the Team a bit about their coworkers.

The democracy of Planning Poker is very different from Traditional Project Planning. Traditionally, only an individuals expert viewpoint is used as a Measure of effort for a specific activity or Feature. What is being Estimated in Agile is not the time required to complete a Task, but the Effort required. There are various Units of Measure which can be utilized, too.

Planning Poker: Points, T-Shirts and Fibonacci Series.

It is always important to remember that this is an Estimate. 100% Accuracy is not possible, nor is it expected. Just enough believed and effort needs to be applied by the Team to get an Estimate for each User Story.

The Cards for Planning Poker can use various sets of Values, ranging from 1,2,3 … 10 to a Fibonacci Sequence. Within the Fibonacci Sequence the next number in the Sequence is the sum of the previous 2 numbers. For example: 1,2,3,5,8, and so on. Some Teams utilize larger numbers: 50, 100, 150, 200. Larger numbers are fine, but the trick is to minimise the options available to the Players. Where a Team member is having a hard time to make a choice, they can utilize previously Estimated Stories as a Yardstick. For instance “is this Story harder or simpler than User Story number 3, which we provided a score of 5”.

When all the Stories have been Estimated, and the Velocity for a Sprint is known; it is the amount of all the Estimates for the User Stories in the Sprint Backlog.

We found these books great for finding out more information on Agile Scrum:

Planning Poker: Estimating for Large Projects.

Where there are several Teams within a Project, it is important to schedule some joint Planning sessions. Within these sessions all the Teams are included and Communicate a Common Yardstick for Estimation. It is no use if one Team has a different set of Goalposts from the other Teams. The Sprint Velocities would then vary by Team for the same amount of Effort, rendering the Estimation of little Value.

Re-estimating, the Good, the Bad and the Pointless.

Re-estimating is an even touchier subject than Estimating, but it does have a part to play. Among the pillars of Agile is the expectation of Change. This means that new User Stories will develop and existing, Estimated Stories will Change. Likewise, the knowledge of the Team increases and the capability to Estimate improves as the Project Progresses.

A common situation where Re-estimation can be applied is where a User Story was not finished in the previous Sprint. The User Story now needs to be finished in the next Sprint. Let us say it had an Estimate of 8, there are 3 alternatives:-

• The Story Value for the previous Sprint was zero. The User Story will be assigned the estimation of 8 in the new Sprint. If the Story was not Delivered in its whole, no Points are acknowledged in the previous Sprint.
• The 8 points are accepted as total in the previous Sprint. Points of zero are awarded for completion of the Story in the present Sprint.
• Some of the Points are awarded to the previous Sprint (say 5). The remaining Work is Re-estimated for the present Sprint. Preferably, the remaining Points should be 3. However the factor for lack of completion may be that the original Estimate did not cater properly for the complexity of the User Story, so it might be greater.

Some Teams invest time Re-Estimating finished Stories. There is little Value-Add in this circumstance, because this is an Estimate, not an Actual. Lessons can be learnt going forward, and the only effect of Re-Estimating completed Work is that the Velocity for a completed Sprint is altered. This affects the ability of the Team to commit to the appropriate Volume of Work for the next Sprint. This is due to the fact that the Velocity Defines how many User Stories can be loaded into the Sprint Backlog. It could take a couple of Sprints to re-establish what the Velocity for future Sprints will be.

We found these books great for finding out more information on Agile Scrum:

The Value of Estimating.

Unless a Team is very mature and understand all the Strengths and Weaknesses within a Team, Estimating should not be dispensed with. It helps build the Team and gives Stakeholders some Measure as to what will be completed when. Estimates establish a Value for Sprint Velocity. This can be used by the Team to make an accurate commitment to the Work they can complete in subsequent Sprints. It also gives an indication to other Teams in large Projects as to completion of specific User Stories on which they are dependent. Estimates also improve the understanding of everyone in the Team as to their own capabilities when they commit to a Story and helps them gauge how much effort they have to put in for similar Work in the Future.The Scrum Team can review the Sprint Deliverables and estimation accuracy within the Sprint Review and Sprint Retrospective Meetings.