Scrum Planning Poker Story Points

During Sprint Planning, after decomposition of Product Backlog Items (which your Team selected for current Sprint) to tasks, Team should make estimation of these tasks. It is necessary for low-level planning. First of all, accuracy of this estimation is much more higher that accuracy of Story Time estimation.

• Examples Of Story Points Scrum

Effective estimation is one of the toughest challenges software developers face in their jobs. Regardless of team size, they need to define, estimate, and distribute work throughout a team. As teams get larger, it becomes even more important to build good habits around planning and estimating work. Lack of planning and estimating reduce confidence in a program, breaks down relationships between the team and the business, and makes development harder on everyone.

Best Scrum Software Every Project Needs

A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.

The Accuracy of Group vs. Individual Estimation

According to some study on the accuracy of estimation of effort between individual and group in an experiment for a software project. 20 software professionals from the same company individually estimated the work effort required to implement the same software development project. The participants had different background and roles and the software project had previously been implemented. After that, they formed five groups. Each group agreed on one estimation by discussing and combining of the knowledge among them.

Result – The estimates based on group discussions were more accurate than the individual estimates.

What is Planning Poker?

Planning poker (also known as Scrum poker) is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development.

Steps for Planning Poker

1. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
   For example:
   “Customer logs in to the reservation system”
   “Customer enters search criteria for a hotel reservation”
2. Team members of the group make estimates by playing numbered cards face-down to the table without revealing their estimate (Fibonacci values: 1,2,3,5,8,13,20,40)
3. Cards are simultaneously displayed
4. The estimates are then discussed and high and low estimates are explained
5. Repeat as needed until estimates converge

By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

Agile Estimation – Relative vs Absolute

An estimate is nothing more than a well educated guess. We use all the knowledge and experience at hand to make a guess about the amount of time it is going to take. So instead of looking at every new work item separately, why not compare it to previously finished work items? It’s easier for humans to relate to similar items than to guess the actual size of things anyway.

For example, is it closer to this really small thing? Or is it more like this normal sized item? Or is it really huge like that one piece of work we finished last month? Doing relative estimates will not only reduce the amount of time spent on estimating work, it will also heavily increase the accuracy of the estimates.

Examples Of Story Points Scrum

Our brain is not capable of doing absolute estimates; we always put that new thing that we need to estimate in relationship to things we already know.

Fibonacci sequence and Planning Poker

Planning Poker uses of the Fibonacci sequence to assign a point value to a feature or user story. The Fibonacci sequence is a mathematical series of numbers that was introduced in the 13th century and used to explain certain formative aspects of nature, such as the branching of trees. The series is generated by adding the two previous numbers together to get the next value in the sequence: 0, 1, 1, 2, 3, 5, 8, 13, 21, and so on.

For agile estimation purposes, some of the numbers have been changed, resulting in the following series: 1, 2, 3, 5, 8, 13, 20, 40, 100 as shown in the Figure below:

The Interpretation of the point assigned to a poker card is listed in the table below:

Point vs Hour Value in Estimation

So why use story points instead of time values? Story pointing allows the team to focus on the complexity and time involved in delivering a piece of work. The team compares the new work against work they’ve already done. They compare the complexity of the new assignment against past challenges and rank the difficulty as well as the time required.

For example, we don’t often account for “the cost of doing business.” Meetings, email, code reviews, etc. with time values. But in reality, all these are necessary practices throughout in our daily life, but don’t actually count as “work.” Story points isolate the software development work from the associated logistic work items, so estimates using point based should more consistent than hour base approach.

Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

Planning poker is a variation of the Wideband delphi method. It is most commonly used in agile software development, in particular in Scrum and Extreme Programming.

The method was first defined and named by James Grenning in 2002^[1] and later popularized by Mike Cohn in the book Agile Estimating and Planning,^[2] whose company trade marked the term ^[3] and a digital online tool.^[4]

• 1Process

Process[edit]

Rationale[edit]

The reason to use planning poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants' sizing. Planning poker should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their card at the same time.

Equipment[edit]

Planning poker is based on a list of features to be delivered, several copies of a deck of cards and optionally, an egg timer that can be used to limit time spent in discussion of each item.

The feature list, often a list of user stories, describes some software that needs to be developed.

The cards in the deck have numbers on them. A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions with a fixed ratio between each value such as 1, 2, 4, 8, etc.

The reason for using the Fibonacci sequence instead of simply doubling each subsequent value is because estimating a task as exactly double the effort as another task is misleadingly precise. A task which is about twice as much effort as a 5, has to be evaluated as either a bit less than double (8) or a bit more than double (13).

Several commercially available decks use the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and optionally a ? (unsure), an infinity symbol (this task cannot be completed) and a coffee cup (I need a break, and I will make the rest of the team tea). The reason for not exactly following the Fibonacci sequence after 13 is because someone once said to Mike Cohn 'You must be very certain to have estimated that task as 21 instead of 20.' Using numbers with only a single digit of precision (except for 13) indicates the uncertainty in the estimation. Some organizations^[which?] use standard playing cards of Ace, 2, 3, 5, 8 and king. Where king means: 'this item is too big or too complicated to estimate'. 'Throwing a king' ends discussion of the item for the current sprint.

Smartphones allow developers to use mobile apps instead of physical card decks. When teams are not in the same geographical locations, collaborative software can be used as replacement for physical cards.

Procedure[edit]

At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

• A Moderator, who will not play, chairs the meeting.
• The Product Owner provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded, e.g. by the Moderator.
• Each individual lays a card face down representing their estimate for the story. Units used vary - they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
• Everyone calls their cards simultaneously by turning them over.
• People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
• Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the 'consensus vote', although the Moderator can negotiate the consensus.
• To ensure that discussion is structured; the Moderator or the Product Owner may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.

The cards are numbered as they are to account for the fact that the longer an estimate is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to reconsider and either work through that some of the perceived uncertainty does not exist and play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.

Benefits[edit]

A study by Moløkken-Østvold and Haugen^[5] reported that planning poker provided accurate estimates of programming task completion time, although estimates by any individual developer who entered a task into the task tracker was just as accurate. Tasks discussed during planning poker rounds took longer to complete than those not discussed and included more code deletions, suggesting that planning poker caused more attention to code quality. Planning poker was considered by the study participants to be effective at facilitating team coordination and discussion of implementation strategies.

See also[edit]

• Comparison of Scrum software, which generally has support for planning poker, either included or as an optional add-on.

References[edit]

1. ^'Wingman Software | Planning Poker - The Original Paper'. wingman-sw.com. Retrieved 5 July 2017.
2. ^Mike Cohn (November 2005). 'Agile Estimating and Planning'. Mountain Goat Software. Retrieved 1 February 2008.
3. ^'Planning poker - Trademark, Service Mark #3473287'. Trademark Status & Document Retrieval (TSDR). 15 January 2008. Retrieved 26 May 2014.
4. ^Cohn, Mike. 'Planning Poker Cards: Effective Agile Planning and Estimation'. Mountain Goat Software. Mountain Goat Software. Retrieved 30 March 2016.
5. ^K Moløkken-Østvold, NC Haugen (10–13 April 2007). 'Combining Estimates with Planning Poker—An Empirical Study'. 18th Australian Software Engineering Conference. IEEE: 349–58. doi:10.1109/ASWEC.2007.15. ISBN978-0-7695-2778-9. Retrieved 1 February 2008.

• Mike Cohn (2005). Agile Estimating and Planning (1 ed.). Prentice Hall PTR. ISBN978-0-13-147941-8.