Why You Should Ditch Your Old Way of Estimating

The Problem

Many organizations struggle in a few key areas when converting and scaling up to an Agile environment from traditional Waterfall methodology. Many teams struggle to effectively create and forecast those user stories until completion of the project. Many teams try to convert to Agile by simply doing ‘development sprints’ and forget about the subsidiary aspects of Agile development. Failure in these key areas often causes the organization to prematurely arrive at the determination to call off their investment in Agile.

I’ve seen teams regress back to Waterfall at the will of stakeholders because they fail to properly implement and understand Agile Estimation techniques. Traditional Waterfall estimation techniques differ from Agile techniques in a few key areas.

Traditional Estimation Techniques

Many of the estimation techniques revolved around waterfall tend to be focused around exact estimates, isolated team members, and functional areas.

  • Teams try to provide estimates in terms of exact hours during the planning phase.
  • Delphi technique — Getting input from subject matter experts in functional areas. The team is often not involved in these conversations.
  • Estimating by functional group —Similar to the Delphi technique. The key difference here is getting estimates from experts in functional areas (i.e. QA, Front End Dev, Systems Development, etc.)
  • Work estimates are generally not expected to change throughout the project.

Why Are These Behaviors Bad?

in Waterfall, estimation is considered a subset of the Planning phase which generally happens once at the beginning of the project. There is no room for the team to revisit the provided estimates down the line during the execution phase of the project. The margin for error when estimating in exact hours is much higher compared to relative sizing due the vast amount of uncertainties in software development.

If changes occur during a waterfall project the team does not revisit and re-estimate future work for any residual changes.

This can cause ‘Trust Issues’ within stakeholder groups. If the teams fall behind on the provided exact hour estimates during he execution phase, the team is immediately considered behind and the only option is to extend the timeline, work overtime or cut features, all of which are BAD.

Agile Estimation Techniques

Planning poker

Oftentimes referred to as ‘Scrum Poker’ is a gamified way of driving the team to develop a consensus on the relative size of a work item.

  • Promotes anonymous estimates.
  • Prevents Subject Matter Experts from anchoring estimates.
  • Relative sizing — Choose story points in relation to similar work done in the past.
  • Eliminates hours from the equation
  • Project specific
  • More accurate as time progresses and team iterates on their estimates
  • Allows better project forecasting once team velocity is determined

Fibonacci Sizing

  • The Fibonacci sequence is a series of numbers where a number is found by adding up the two numbers before it. Starting with 0 and 1, the sequence goes 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so forth.
  • The more complex a problem is to solve the estimate tends to grow exponentially
  • Uncertainty grows proportionally with the size of the story. This allows stakeholders to better prioritize uncertain stories.
  • Helps to easily identify complex problems that need to be further refined with the team

Agile Benefits over Traditional Waterfall Estimations

Many times stakeholders complain how Waterfall projects are NEVER delivered on time. This is in part due to the natural phased approach of Waterfall and how we allot a single phase to perform estimations. In waterfall you have ONE chance to get the estimates right. If your wrong during the single planning phase the whole project can be thrown off leaving the team behind schedule without a chance to re-baseline the estimates.

Agile enhances this process by reassessing the plan at the end of every development sprint. Estimating in a relative and often manner, provides various opportunities for teams to learn and enhance their methods of estimating.

These consensus driven approaches allow the team who is performing the work to come to an agreement on what the relative size should be regardless of skillets or subject matter knowledge. Ultimately, because the team feels more comfortable with the estimates provided in the Agile framework, this will translate into easier to meet deadlines that will in turn eliminate aforementioned ‘trust issues’.

Follow me for future articles related to Agile methods and details into Agile implementation.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.