20 September 2024

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