Planning Poker Slideshare
- Planning Poker Slideshare Free
- Planning Poker Slideshare Download
- Planning Poker Slideshare Pdf
- Planning Poker Slideshare Tutorial
- Estimation Techniques Tutorial
So this week we revisited our project backlog and introduce a new Agile method to the mix: planning poker. Planning poker The idea behind planning poker is very simple: “planning poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development” ( Wikipedia ).
- Estimation Techniques Resources
A poker planning, or scrum poker session involves product owners or customers and editors. The session begins with each estimator holding a deck of value-based cards ranging in sequence. We recommend the following: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. Planning poker agile Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. When planning, we use a tool called planning poker to help estimate the relative size of tasks. Planning poker, or Scrum poker, is a very effective, collaborative planning tool that was first defined by James Grenning in 2002, and made popular by Mike Cohn, founder of Mountain Goat Software. 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.
- Selected Reading
Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.
Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on −
- Past Data/Past Experience
- Available Documents/Knowledge
- Assumptions
- Identified Risks
The four basic steps in Software Project Estimation are −
- Estimate the size of the development product.
- Estimate the effort in person-months or person-hours.
- Estimate the schedule in calendar months.
- Estimate the project cost in agreed currency.
Observations on Estimation
Estimation need not be a one-time task in a project. It can take place during −
- Acquiring a Project.
- Planning the Project.
- Execution of the Project as the need arises.
Project scope must be understood before the estimation process begins. It will be helpful to have historical Project Data.
Project metrics can provide a historical perspective and valuable input for generation of quantitative estimates.
Planning requires technical managers and the software team to make an initial commitment as it leads to responsibility and accountability.
Past experience can aid greatly.
Use at least two estimation techniques to arrive at the estimates and reconcile the resulting values. Refer Decomposition Techniques in the next section to learn about reconciling estimates.
Plans should be iterative and allow adjustments as time passes and more details are known.
General Project Estimation Approach
The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition techniques take a divide and conquer approach. Size, Effort and Cost estimation are performed in a stepwise manner by breaking down a Project into major Functions or related Software Engineering Activities.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.
Start with the statement of scope.
Decompose the software into functions that can each be estimated individually.
Calculate the size of each function.
Derive effort and cost estimates by applying the size values to your baseline productivity metrics.
Combine function estimates to produce an overall estimate for the entire project.
Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates by breaking down a project into related software engineering activities.
Identify the sequence of activities that need to be performed for the project to be completed.
Divide activities into tasks that can be measured.
Estimate the effort (in person hours/days) required to complete each task.
Combine effort estimates of tasks of activity to produce an estimate for the activity.
Obtain cost units (i.e., cost/unit effort) for each activity from the database.
Compute the total effort and cost for each activity.
Combine effort and cost estimates for each activity to produce an overall effort and cost estimate for the entire project.
Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if widely divergent estimates occur conduct further investigation concerning whether −
The scope of the project is not adequately understood or has been misinterpreted.
The function and/or activity breakdown is not accurate.
Historical data used for the estimation techniques is inappropriate for the application, or obsolete, or has been misapplied.
Step 5 − Determine the cause of divergence and then reconcile the estimates.
Estimation Accuracy
Accuracy is an indication of how close something is to reality. Whenever you generate an estimate, everyone wants to know how close the numbers are to reality. You will want every estimate to be as accurate as possible, given the data you have at the time you generate it. And of course you don’t want to present an estimate in a way that inspires a false sense of confidence in the numbers.
Important factors that affect the accuracy of estimates are −
The accuracy of all the estimate’s input data.
The accuracy of any estimate calculation.
How closely the historical data or industry data used to calibrate the model matches the project you are estimating.
The predictability of your organization’s software development process.
The stability of both the product requirements and the environment that supports the software engineering effort.
Whether or not the actual project was carefully planned, monitored and controlled, and no major surprises occurred that caused unexpected delays.
Following are some guidelines for achieving reliable estimates −
- Base estimates on similar projects that have already been completed.
- Use relatively simple decomposition techniques to generate project cost and effort estimates.
- Use one or more empirical estimation models for software cost and effort estimation.
Refer to the section on Estimation Guidelines in this chapter.
To ensure accuracy, you are always advised to estimate using at least two techniques and compare the results.
Estimation Issues
Often, project managers resort to estimating schedules skipping to estimate size. This may be because of the timelines set by the top management or the marketing team. However, whatever the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to accommodate the scope changes.
While estimating, certain assumptions may be made. It is important to note all these assumptions in the estimation sheet, as some still do not document assumptions in estimation sheets.
Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often treated as though they are accurate.
The best way of expressing estimates is as a range of possible outcomes by saying, for example, that the project will take 5 to 7 months instead of stating it will be complete on a particular date or it will be complete in a fixed no. of months. Beware of committing to a range that is too narrow as that is equivalent to committing to a definite date.
You could also include uncertainty as an accompanying probability value. For example, there is a 90% probability that the project will complete on or before a definite date.
Organizations do not collect accurate project data. Since the accuracy of the estimates depend on the historical data, it would be an issue.
For any project, there is a shortest possible schedule that will allow you to include the required functionality and produce quality output. If there is a schedule constraint by management and/or client, you could negotiate on the scope and functionality to be delivered.
Agree with the client on handling scope creeps to avoid schedule overruns.
Failure in accommodating contingency in the final estimate causes issues. For e.g., meetings, organizational events.
Resource utilization should be considered as less than 80%. This is because the resources would be productive only for 80% of their time. If you assign resources at more than 80% utilization, there is bound to be slippages.
Estimation Guidelines
One should keep the following guidelines in mind while estimating a project −
During estimation, ask other people's experiences. Also, put your own experiences at task.
Assume resources will be productive for only 80 percent of their time. Hence, during estimation take the resource utilization as less than 80%.
Resources working on multiple projects take longer to complete tasks because of the time lost switching between them.
Include management time in any estimate.
Always build in contingency for problem solving, meetings and other unexpected events.
Allow enough time to do a proper project estimate. Rushed estimates are inaccurate, high-risk estimates. For large development projects, the estimation step should really be regarded as a mini project.
Where possible, use documented data from your organization’s similar past projects. It will result in the most accurate estimate. If your organization has not kept historical data, now is a good time to start collecting it.
Use developer-based estimates, as the estimates prepared by people other than those who will do the work will be less accurate.
Use several different people to estimate and use several different estimation techniques.
Reconcile the estimates. Observe the convergence or spread among the estimates. Convergence means that you have got a good estimate. Wideband-Delphi technique can be used to gather and discuss estimates using a group of people, the intention being to produce an accurate, unbiased estimate.
Re-estimate the project several times throughout its life cycle.
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]
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 coffee). 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.
Planning Poker Slideshare Free
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]
Planning Poker Slideshare Download
- ^'Wingman Software Planning Poker - The Original Paper'. wingman-sw.com. Retrieved 5 July 2017.
- ^Mike Cohn (November 2005). 'Agile Estimating and Planning'. Mountain Goat Software. Retrieved 1 February 2008.
- ^'Planning poker - Trademark, Service Mark #3473287'. Trademark Status & Document Retrieval (TSDR). 15 January 2008. Retrieved 26 May 2014.
- ^Cohn, Mike. 'Planning Poker Cards: Effective Agile Planning and Estimation'. Mountain Goat Software. Mountain Goat Software. Retrieved 30 March 2016.
- ^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.
Planning Poker Slideshare Pdf
- Mike Cohn (2005). Agile Estimating and Planning (1 ed.). Prentice Hall PTR. ISBN978-0-13-147941-8.