The Awesome Singh Estimation Technique (TASET)


I spoke to the DC Scrum Users Group this topic around a year ago and wanted to unleash this virus on the world. The Awesome Singh Estimation Technique (TASET) is a technique learned from Alex Singh and honed over the course of two years while working with BigVisisble’s clients and recently while working with my own clients at ResultLinq Associates.

The Problem

Managers in every business and from every walk of life always ask the same questions when it comes to Product Development and IT projects: How long is going to take and how much is it going to cost?

When teams are learning relative sizing (estimation) of work items (user stories) it takes some time for the team to get good at estimations. {> Horrible sentence structure <} Traditional methods of estimation consistently fail teams in the early stages of adopting Agile product development practices and are often abandoned in the absence of managerial support. Intellectually, managers understand that it takes a team a while to develop the skills that enables accurate forecasts of feature delivery. {> I should write a blog about the futility of attempting to forecast more than 3 months into the future without having a large enough data pool to use for estimation. <}

There are several approaches to answer this question when employing Agile product development techniques, but at the heart of every approach are two principles:

  • Humans are terrible at estimating effort and complexity of work products [^1]:
  • Teams can only predict once they have a consistent record of estimating effort and complexity [^2]

I’ve run into the problem of estimating time and again when working with organizations adopting the Agile way to product delivery.

What I’ve tried

Many teams adopt the concept of story points and use Mike Cohn’s approach of planning poker. This works really well for a lot of people, but I’ve struggled with teams needing to get “stable” with their estimations as quickly as possible due to management pressure to answer the above question in the absence of mature adaptive management of product delivery and lean thinking.

Techniques I’ve tried are:

  • Using Story Points and Planning Poker
  • T-Shirt Sizes (Extra-Small, Small, Medium, Medium Large, Large, Extra Large, etc.)
  • Using Ideal Man Days
  • Using 3-Factor Hour Estimation (PERT): Optimal, Normal, Pessimistic
  • Story Point estimation + Hourly Estimates on Tasks
  • Using Scrumban’s Cycle Time, Lead Time, Lag Time estimates

Alex to the rescue

Unfortunately, none of these techniques helped me get a team stable at estimating very quickly. Fortunately, my BigVisible colleague, Alex Singh, shared a nice derivative technique that allows me to focus the team on execution while taking care of the problems associated with relative sizing using story points.

Estimating using TASET

The person facilitating the estimation session starts by creating cards as column labels and placing them horizontally on a wall to be used for the estimating exercise. The labels are:

  • Piece of Cake
  • Easy
  • Moderate
  • Somewhat Hard
  • Hard
  • Very Difficult
  • Extreme But Known, and
  • Extreme and Unknown 

At the same time, the person responsible for User Story creation and elaboration (typically a Business Analyst or the Product Owner) should have the stories in order of priority from highest business value to lowest business value.

TIP: Place a small number on each card to indicate the prioritization relative to the other cards (e.g. BV1 BV2, .. , BVn).

When the session begins, starting with the first story, the person responsible for the first story explains the first story to the team members who will be performing the work. Using the round-robin selection approach, the first team member places the user story in the column matching the size most closely matching their estimate for the story and then explains the rationale for their estimate. Then the next team member takes the same story and either agrees with the estimate or moves it to the column most closely matching their estimate and explains why they did or did not move it. In a similar manner, each team member repeats this process until all team members have had a chance to re-estimate and explain their rationale. You now have a baseline story to use relative estimation sizing.

The next story is explained by the Product Owner.

Estimate the size of a user story relative to similar stories in previous products and releases with each person by first explaining which previous product and release they are using for comparison and then placing that story under the appropriate column heading.

This should be specfiic for each of the delivery groups in the room. The Business Analyst or the Product Owner then explains the stories in order of priority from highest value to lowest value to the business. The track/team lead then facilitates moving the first story to the appropriate column heading (estimate) based on relative size to some previous story from either the previous iteration, is there was one, or previous release, if there was one.

Applying the Technique

  1. Build the Estimation Wall
  2. Find the Smallest Story
  3. Find a Representative Story for Each Relative Size
  4. Walk Through Each Story, discussing as a team the acceptance criteria, the approach to solving for the Acceptance Criteria, and Risks/Dependencies
  5. Poll the team which representative story already on the wall the Story belongs with
  6. After placing the story in the estimation column, ask the team for a confidence vote (Fist of Five) that they got that right.
  7. Adjust the estimation based on the Team’s response
  8. Repeat until all Stories are estimated
  9. Ask for a final confidence vote by the team
  10. Adjust the estimation based on the Team’s response

Why it works

Using relative sizing is to use a scale that activates two levels of the brain, the pre-frontal cortex where we make relational decisions and the basal ganglia where previous experience exists. Often sizes and number confuse a team as it is difficult for a team to pin-down what a size or number really means. This method uses yesterday’s weather in a meaningful and adds a Plan-Do-Check-Act feedback loop so that teams can get to good, reliable estimates within the second or third iteration.

Some other ways to do it

I often have to work with disbursed or distributed teams. When I do, I’ve used a spreadsheet where we collaborate on finding the relative sizes using columns in the spreadsheet. It takes time and patience. I’ve had better luck using Google Sheets where everyone can work on a Sheet at the same time. I’ve heard rumors that Microsoft is working on something similar, and there are plug-ins that are being added by the moment to Rally, VersionOne or Jira.

Post Disclaimer

The information contained on this post is my opinion, and mine alone (with the occasional voice of friend). It does not represent the opinions of any clients or employers.