17 October 2021

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

Leave a Reply

Your email address will not be published. Required fields are marked *