Agile estimation
Agile estimation
– Affinity estimating
– Ideal time
– Ideal days
– Idle Time
– Elapsed Time
– Project buffer
– Project burndown chart
– Relative sizing/story points
– Local safety
– Parking lot chart
– Planning poker
– Product backlog
– Reference point user story
– Story points
– User story
– Revenue
– Velocity
– Wide band Delphi
– Planning poker
Affinity estimating
Affinity estimating is a method to predict the work effort, typically in story points, of developing a user story. It is particularly useful for large product backlogs. Although several methods exist, the basic affinity estimating model involves sizing user stories on a scale from small to large. The scale can be a Fibonacci sequence or t-shirt sizes and is typically taped to a wall in a large conference room. Participants then attach their user stories to the wall as estimates. It is often done in silence and has several iterations until the user stories have been estimated. [The Art of Agile Development. James Shore.]
The Fibonacci sequence begins with 0 and 1 and every successive number is the sum of the previous two numbers. Therefore the Fibonacci sequence begins 0, 1, 1, 2, 3, 5, 8, 13, etc. In planning poker, a 1 is removed because it is redundant. [Agile Estimating and Planning. Mike Cohn.]
When estimating an agile project, a top-down approach is typically used. This involves high-level estimation at first, followed by more detailed estimation. [Agile Estimating and Planning. Mike Cohn.]
Ideal time
Time spent exclusively on the task, with no interruptions and in a good work disposition.
The time we estimate it will take to complete a story uninterrupted (consider this an estimate of size).
Ideal days
Instead of using story points, agile teams may estimate the relative sizes of user stories using ideal days. Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the user story, relative to other user stories in the backlog. [Agile Estimating and Planning. Mike Cohn.]
The agile estimation technique of ideal days ignore, discount, or simplify delays, obstacles, non-working days, and the possibility that multiple developers may work on the user story.
Idle Time
Unproductive time on the part of employees or machines as a result of factors beyond their control. Idle time is the time associated with waiting, or when a piece of machinery is not being used but could be. Idle time could also be associated with computing, and in that case refers to processing time.
Elapsed Time
The actual amount of time it will take to complete the story.
Project buffer
A project buffer is extra time added to the end of a project to account for delays, obstacles, and other unforeseen issues to help predict an accurate completion date. A project buffer can be estimated using several methods.
Three commonly used methods are :
1) square root of the sum of squares method,
2) Critical chain project management method (CCPM),
3) halving the sum of most likely estimates.
The square root of the sum of squares method involves finding a local safety for all tasks, squaring all the local safeties, summing these squares, and then finding the square root of the sum.
The Critical chain project management method (CCPM) is the sum of half the local safeties of all tasks. The local safety is the difference between the 50% confidence estimate and the 90% confidence estimate.
The halving the sum of most likely estimates method involves adding all the most likely estimates and dividing by two. [Agile Estimating and Planning. Mike Cohn.]
The agile practitioner should follow several rules of thumb when estimating a project buffer:
1) Only use a buffer if the project has more than 10 user stories,
2) The square root of the sum of squares method has shown to provide the most accurate buffer,
3) the estimate buffer should be at least 20% of the total project duration,
4) In the absence of sufficient data. like worst case scenario estimates, you can use the halving of most likely estimates to estimate a project buffer. [Agile Estimating and Planning. Mike Cohn.]
Project burndown chart
A project burndown chart is an often used information radiator to show iteration progress. It charts two series: the actual work remaining and ideal/estimated work remaining. The vertical axis is the work unit (often story points or hours) and the horizontal axis is iteration duration (typically in number of days). The ideal/estimated work series is a straight, downward sloping line originating on the vertical axis at the value of work to be completed (e.g., 20 story points) and extending to the horizontal axis (i.e., 0 story points) on the last day of the iteration. The actual series is dependent upon the agile team’s productivity and the task complexity and is updated daily. The actual series is typically volatile and is not a straight line but ebbs and flows as the project team tackles the development process. [Agile Estimating and Planning. Mike Cohn.]
Relative sizing/story points
Agile teams typically use story points to estimate the relative size or effort of developing a user story [Agile Estimating and Planning. Mike Cohn.]
Agile teams should agree to one method of estimation, either story points or ideal days, as both use different units of measurement and can lead to confusion. [Agile Estimating and Planning. Mike Cohn.]
Both planning poker and affinity estimation are agile techniques used to size the work effort of developing user stories. [Agile Estimating and Planning. Mike Cohn.]
Instead of using story points, agile teams may estimate the relative sizes of user stories using ideal days. Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the user story, relative to other user stories in the backlog. [Agile Estimating and Planning. Mike Cohn.]
Local safety
The local safety is the difference between the 90% confidence estimate of task time and the 50% confidence estimate of task time. Remember that estimates for task time are typically a range of estimates and not a single value; think of estimates existing as a cumulative distribution function. A 50% confidence estimate is essentially an aggressive estimate where the estimator only has a 50% confidence that the task will be completed within the associated time value. A 90% confidence estimate is essentially a conservative estimate where the estimator has a 90% confidence that the task will be completed within the associated time value. [Agile Estimating and Planning. Mike Cohn.]
Parking lot chart
A parking lot chart is an agile artifact used to organize and categorize user stories by theme. A parking lot chart typically includes the name of the identified themes, the number of stories and story points it includes, and a progress chart to show the completion percentage of story points. For example, a parking lot chart could have a theme of ‘database’ with 6 user stories worth 80 story points at a 50% completion. A 50% completion would indicate that 40 story points had been completed, but NOT necessarily that 3 stories had been completed because not all stories are equivalent in effort. [Agile Estimating and Planning. Mike Cohn.]
Planning poker
Planning poker is a common agile estimation technique used to estimate the relative point value of a user story. [Agile Estimating and Planning. Mike Cohn.]
Planning poker is based upon the wideband Delphi estimation technique. It is a consensus-based technique for estimating effort. Sometimes called scrum poker, it is a technique for a relative estimation of effort, typically in story points, to develop a user story. At a planning poker meeting, each estimator is given an identical deck of planning poker cards with a wide range of values.
The Fibonacci sequence is often used for values for planning poker (i.e., 0, 1, 1, 2, 3, 5,8,etc.); another common sequence is (question mark, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, and 100).
A planning poker meeting works as follows :
1) a moderator, not estimating, facilitates the meeting.
2) the product owner/manager provides a short overview of the user story and answers clarifying questions posed by the developers. Typically the product owner does not vote.
3) Each estimator selects an estimate of work effort by selecting a card,
4) Once everyone has selected a card, everyone overturns their card concurrently,
5) Estimators with high and low estimates are given a chance to defend positions.
6) The process repeats until there is consensus. The developer who owns the user story is typically given higher credence. [Agile Estimating and Planning. Mike Cohn.]
Product backlog
The product backlog initially serves as a rough estimate of the product’s requirements [Agile Estimating and Planning. Mike Cohn.]
One of the attributes of a Product Backlog is that it is EMERGENT (from the acronym DEEP). It keeps evolving as time progresses. It never gets frozen.
Reference point user story
The reference point user story for planning poker is typically a medium or average size user story. Estimators can use the reference point to make relative estimations. [Agile Estimating and Planning. Mike Cohn.]
Story points
A fixed and relative value of development effort.
Story points represent the relative work effort it takes to develop a user story. Each point represents a fixed value of development effort. When estimating the agile team must consider complexity, effort, risk, and inter-dependencies. [Agile Estimating and Planning. Mike Cohn.]
A story point is a fixed unit of development effort. It is used in the relative sizing of user stories to estimate work effort involved with development. Story points are not time-based, meaning [Agile Estimating and Planning. Mike Cohn.]
Agile teams typically use story points to estimate the relative size or effort of developing a user story [Agile Estimating and Planning. Mike Cohn.]
User story
– User story time-boxed value
Two to three minutes is a typical time-boxed value for discussing user stories when playing planning poker. [Agile Estimating and Planning. Mike Cohn.]
– Triangulation
Triangulation involves estimating the relative effort of developing a user story by comparing it against two other user stories. [Agile Estimating and Planning. Mike Cohn.]
– Vague and unclear user story
When an agile team is scoring a particularly vague and unclear user story, it typically assigns it a high value knowing that it will most likely become further defined in upcoming iterations. [Agile Estimating and Planning. Mike Cohn.]
Assign the user story an arbitrarily high number.
Tasks
It is appropriate to estimate tasks both during iteration planning and throughout the iteration. [Agile Estimating and Planning. Mike Cohn.]
Revenue
– Additional revenue
Additional revenue is revenue realized through the sales of new product features or services to existing customers. [Agile Estimating and Planning. Mike Cohn.]
– Retained revenue
Retained revenue is revenue retained through the development of new product features or services that prevent existing customers from stopping use of the existing product. [Agile Estimating and Planning. Mike Cohn.]
– New revenue
New revenue is revenue realized through the sales of products or services to new customers. [Agile Estimating and Planning. Mike Cohn.]
Velocity
Velocity is a measure of the number of user story points or stories completed by a team per iteration. An agile team can use its previous velocity recordings as a method of estimating how many user story points it may complete in the next iteration. [Agile Estimating and Planning. Mike Cohn.]
Estimating how many user story points a team can complete in a sprint/iteration should be based upon its previous iterations, if possible. If Kyle’s team estimated 45 story points in its first sprint but completed only 30 story points, it would be wise to estimate no more than 30 for its next sprint/iteration. [Agile Estimating and Planning. Mike Cohn.]
Wide band Delphi
A group estimation technique.
The Wideband Delphi estimation method is a consensus-based technique for estimating effort. It derives from the Delphi method which was developed in the 1950-1960s at the RAND Corporation as a forecasting tool. It has since been adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts.
Barry Boehm and John A. Farquhar originated the Wideband variant of the Delphi method in the 1970s. They called it « wideband » because, compared to the existing delphi method, the new method involved greater interaction and more communication between those participating. The method was popularized by Boehm’s book Software Engineering Economics (1981).
Original steps :
– Coordinator presents each expert with a specification and an estimation form.
– Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.
– Experts fill out forms anonymously.
– Coordinator prepares and distributes a summary of the estimates
– Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely
– Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.
Where is it effective ?
For making top-down estimates in situations where there are a lot of unknowns or various kinds of domain knowledge required. Especially useful for early estimates of large, not-yet-well-understood projects — estimates upon which we base our go/no-go decisions and early expectation-setting for upper management and customers.
How does it work?
– step 1 : Schedule the estimation meeting for a particular project or set of projects. The estimators should be team members (and possibly other stakeholders) who are very knowledgeable about the project, and from whom you need buy-in for the schedule of the project. 3-5 estimators is the sweet spot, although much larger groups can work, by breaking them into 3-5 person sub-groups and then combining those estimates.
– step 2 : Describe what the group is estimating. What part of the project, goals, or outcome are we estimating? What types of resources are we going to include? What units (ideal man-days or man-months, story points, etc.) will we use?
– step 3 : Ask everyone to estimate individually and privately using their best, instinctual judgement on the estimate. Give them enough time (5-20 minutes) to do this work quietly. Once people are familiar, you may be able to ask them to do this before the estimation meeting. Ask them also to take note of the assumptions and major pieces of work that led to the estimate — they’ll use these later in the group discussion. The private/anonymous aspect of this first round of estimates is important: we’re specifically empowering each person to express their gut instinct, and not be influenced by group think yet.
– step 4 : Show the results on a spreadsheet or whiteboard, and discuss. The group can see how divergent or convergent their estimates are. Ask each person (but especially the high/low or other interesting estimators) to explain how they got to their estimate — major assumptions, things included, etc. People will be reminded of things they forgot to include in their estimates. They’ll also be forced to confront different assumptions (which you may be able to quickly decide upon). All of which will improve future rounds of estimates.
Repeat steps 3 & 4 for a total of 2-3 rounds. After round one, anonymity is dropped and discussions can be short (the moderator should make decisions on behalf of group, for expediency and just for the purposes of the estimate). Often only 2 rounds total are needed to see estimates converge somewhat. A common effect is estimates converge together and up as people realize from the discussions the things they missed from their initial estimates.
Planning poker
Planning poker is based upon the wideband Delphi estimation technique. It is a consensus-based technique for estimating effort. Sometimes called scrum poker, it is a technique for a relative estimation of effort, typically in story points, to develop a user story. At a planning poker meeting, each estimator is given an identical deck of planning poker cards with a wide range of values. The Fibonacci sequence is often used for values for planning poker (i.e., 0, 1, 1, 2, 3, 5, 8, 13, etc.).
A planning poker meeting works as follows:
1) a moderator, not estimating, facilitates the meeting.
2) the product owner/manager provides a short overview of the user story and answers clarifying questions posed by the developers. Typically the product owner does not vote.
3) Each estimator selects an estimate of work effort by selecting a card,
4) Once everyone has selected a card, everyone overturns their card concurrently,
5) Estimators with high and low estimates are given a chance to defend positions.
6) The process repeats until there is consensus. The developer who owns the user story is typically given higher credence. [Agile Estimating and Planning. Mike Cohn.]
Advices :
1) a moderator, not estimating, facilitates the meeting
2) the product owner/manager provides a short overview of the user story and answers clarifying questions posed by the developers. Typically the product owner does not vote
3) Each estimator selects an estimate of work effort by selecting a card
4) Once everyone has selected a card, everyone overturns their card concurrently
5) Estimators with high and low estimates are given a chance to defend positions
6) The process repeats until there is consensus
7) The developer who owns the user story is typically given higher credence
Planning poker = scrum poker
The presence of a product owner is necessary when playing a game of planning poker because the product owner provides an overview of user stories and answers any questions the development team may have.
Leave a Reply
You must be logged in to post a comment.