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
• Wide band Delphi
• Planning poker
• Product backlog
• Reference point user story
• Story points
• User story
• Revenue
• Velocity

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 User Story.

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.

Wide band Delphi

• Wide band Delphi is 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.
    • 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 Developers may have.
    • 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. [Agile Estimating and Planning. Mike Cohn.]
• Planning poker = scrum poker

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.]

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 :
    • Square root of the sum of squares method
      • 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 local safety is the difference between the 50% confidence estimate and the 90% confidence estimate.
    • Critical chain project management method (CCPM)
      • 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.
    • Halving the sum of most likely estimates
      • 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:
  • Only use a buffer if the project has more than 10 user stories,
  • The square root of the sum of squares method has shown to provide the most accurate buffer,
  • The estimate buffer should be at least 20% of the total project duration,
  • 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.]

Story points

• Story points is a fixed and relative value of development effort.
  • Story points represent the relative work effort it takes to develop a User Story.
    • Agile teams typically use story points to estimate the relative size or effort of developing a User Story [Agile Estimating and Planning. Mike Cohn.]
  • Each point represents a fixed value 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.
  • When estimating the agile team must consider complexity, effort, risk, and inter-dependencies.
  • [Agile Estimating and Planning. Mike Cohn.]

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.]

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.]
• 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 Product Backlog. [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.]

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.]

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 User 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.]

More informations at PMI-ACP exam