Tag: Planning

The Awesome Singh Estimation Technique (TASET)

Introduction

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.

Dealing with Sunday Anxiety

A set of playground seesaws.
A set of playground seesaws.

A colleague posted a question to our support forum with the following question:

I try to keep my Sundays focused on non-work. This evening, like many Sunday evenings, my brain is already attempting to plan my Monday. And then it wants to start working my Monday.

What are your tricks for keeping your off-work time full of non-work thoughts?

The irony is that while he would have posting this question, I was dealing with the same thoughts. Yesterday I was running through all the things I had to do, and all the things I was behind on. “Eat that frog!” kept running around in my head. Do I focus on the things I can just knock and feel a sense of accomplishment, or do I prioritize my work by importance/value and burn it down?

Here is my list of “turn it off” techniques for dealing with “Sunday Anxiety”:

1) Make one list: Only use one list.

2) Prioritize the list. I start with the Franklin Planner (NOT Franklin-Covey) approach of prioritization.

3) Next I categorize the list using the Franklin-Covey approach: Urgent and important, not-urgent and important, urgent and not important, and not-urgent and not important.

4) Cross out the not-urgent and not important items. (THIS PART IS IMPORTANT!) It clears away the junk that clouds my mind.

5) Find the Frog you need to eat and flip it to the top. (It should already be there, but the brain has a tendency to procrastinate or avoid the Frog because the Frog is ugly.

6) Find a few small things to sprinkle near the top to give you a sense of accomplishment.

7) Meditate/mindfulness

8) Read Bible

9) Meditate/mindfulness again

10) Contemplate the Frog. What makes is a Frog? Usually, what makes the Frog ugly is that the Frog is really an “Epic” thing comprising a lot of smaller things. One way to turn the Frog into a something more approachable is to break the Frog apart into those smaller things, then throw those smaller things back into the master list and reprioritize without losing the overall sense that you have to now do those N-number of things to Eat that Frog, but you also get the sense that you will be accomplishing something. You are activating the reward system of the brain.

I try to do this everyday. Sometime I fail. When things are really looking scary, I go work out or do something physical like yard work or chores. The trick is to find something that requires me to arrest my limbic system. (Read “Your Brain at Work” by David Rock)

Hope this helps.

 

General Patton on Planning

“If everyone is thinking alike, then somebody isn’t thinking.”