# Agile WAGs?

“To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.” — Chinese proverb”

Agile WAG (Wild Approximation and Guess). Many Agile team ask this question at the beginning of every iteration. This article captures some of the many methods of forecasting deliverable within an Agile team. Although other methods are available, these seems to be the simplest to manage and implement

Traditional software teams give estimates in a time format: days, weeks, months. But agile team’s users story points. Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. in simple terms its a number that tells the team how hard the “user story” is

**User Stories Method**:A user story is “a description of a requirement”. One way to estimate is to assign user story points to each task, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2.5 hours per point;

**Estimating User Stories**: The first step is to put estimates against the User Stories. It is also a relative measure so a User Story of two Story Points is twice the size of a one Story Point . User Story contains Work Unit and Ideal time .

**Work Units**: A Work Unit is a relative measure that is close to actual time. Some such units: Points.

Ideal Time: Ideal Time excludes non-programming time. Ultimate effort exceeds initial programmer estimates by 1–2x. Stabilize ideal time over iteration with acceptable range. If high level estimate = 200 ideal days

(Ideal estimate)/ (real estimate) , ratio= 2.5

Assuming 2.5 is historical for the team, then estimate = 500 project days

**Example** -Build a model in excel or use tools such as ‘versionone’ and estimate projects/features on-time for each release An example of a model is presented here. The template used has Feature step wise and get to the total points. The first step is to include or exclude a area, Step 2 is to put comments on them, a Factor for complexity is step 3. Step 4 is to put 1 against the Trivial (.1)Simple(1), normal (2) , complex(4), challenging(8) and Impossible(99) .

**Wideband Delphi Method**: The Wideband Delphi estimation method is a consensus-based technique for estimating effort. Kickoff Meeting: At least three people discuss the source documents and project, as well as the units of estimation. Estimation: Each person creates three estimates (using his/her preferred method): most likely, optimistic, pessimistic case. Meeting: Each estimator gives his/her estimates to the facilitator who displays them with averages (owners of the estimates may not be revealed to reduce the influence of personality or seniority). Each estimator discusses the insights, problems and assumptions. Repeat steps stated before at least once to get iterative estimation refinement: let the feedback drive adaptation and improvement. Calculate the final numbers using the averages from the final cycle.

Estimate = (Optimistic + Pessimistic + 4 * Most likely) / 6

Likely Deviation = (Pessimistic — Optimistic) / 6

Wideband Delphi sits on top of any other estimation method, improving it through multiple participants, feedback, and iterative refinement

**Example below**

**First estimates** : It is tough to estimate story points for first set of requirement . Take a rough approach to arrive at the forecast for the very first iteration:

- Estimate high-priority items from the ‘backlog’ using story points. Requirements should be small to be completed in a single iteration.Break down the highest-priority requirement into granular tasks.
- Estimate (in hours) how much time will it take to finish individual tasks. Factor 6 hours as productive day. Add up the estimates and check if the team has capacity to commit this requirement for first iteration.
- Repeat this exercise for rest of the requirements, moving down through the backlog until the team runs out of available capacity for this iteration.

This exercise is time-consuming. It should become consistent with iteration. Usually the estimates will change with experience. Once the first iteration is completed, teams improvises for better forecasts.

Tips For Accurate Estimates: You can have accurate estimates if you: Estimate in terms of ideal engineering days (story points), not calendar time. Use “velocity” to determine how many story points the team can finish in an iteration.Use iteration “slack” to smooth over surprises and deliver on time every iteration.Use risk management to adjust for risks to the overall release plan.

**Conclusion**: The sooner the team starts estimating points , the more effective point valuations will become. Over a period of time , every team can become more adept at estimating new stories and develop its own scale for points that will factor into its own velocity. Care should be taken that historical data is well maintained and referred to regularly to improve the team’s estimations. This, in turn, improves the forecast and productivity of the development team and helps them be truly Agile.

*PS: if you liked this article and feel that it deserves a clap or a coffee , then please do so @ **https://ko-fi.com/anilyad*