Story Triangulation

Imagine, if you will...

• • You are part of an Agile software development team.

  • You have a Backlog of previously estimated Stories.

  • Rightly so, your Customer has provided some feedback and your team decides to create a new Story.

  • In order to plan this Story for an upcoming Iteration or Sprint, your team needs to estimate the Story.

Now what? How does your team arrive at the estimate? A few (ineffective) popular methods are

• 1. Pull it out of thin air.

  2. Ask the most senior member of your team.

  3. Both 1 and 2.

A much more effective technique is called Story Triangulation, a slight variation of classic Planning Poker.

Story Triangulation bases the estimate for new stories completely upon the estimates of previous Stories in your Backlog. It is indisputable that the new story is either easier, harder, or the same effort as previous Stories in your Backlog. Therefore, you have plenty of reference points for comparison.

For example, if the new story has similar size, complexity, and risk as a previous Story valued at 8 Story Points, then the new story should be estimated as 8 Story Points. If it is about 50% harder than a previous 2 Point Story, then the new story should be estimated as 3 Story Points.

The main benefits of estimated based upon previous stories instead of as independent events are as follows:

• 1. Minimize the effects of CYA, cooking the Velocity books to make your team look "better", and emotion.

  2. As your team practices and refines the technique, you will find estimations to be much easier, faster, and more accurate.* Therefore, predicting how many points you can complete this Iteration becomes more likely.

  3. Because your delivery becomes more and more predictable, the trust your customer and boss has for your team increases like the size of snowball rolling downhill**.

A more detailed version of a typical Planning Poker / Story Triangulation session:

• 1. The moderator presents a high level description of new Stories numbered 8888 and 9999.

  2. The team collaborates and agrees upon assumptions needed to simplify the estimate.

  3. Using the extremely convenient Story Triangulation iPhone app, each team member brings up a list of recently estimated Stories. For example,

     1. Story 5555 was 2 Story Points.

     2. Story 2222 and 3333 were both 5 Story Points.

     3. Story 4444 was 20 Story Points.

  4. Each team member finds a Story with similar size, risk, and complexity to the new Story. For example, Story 9999 seems about the same as Story 2222.

  5. Then, he or she touches that Story name, bringing up the estimate for the new Story. Therefore, the estimate for Story 9999 is 5 story points.

  6. If a similarly sized story does not exist, find an existing Story and ask, "Is the new Story X% easier/harder than an existing Story?" For example,

• • 1. Story 8888 seems harder than 2222, but easier than 4444.

• 7. Does Story 8888 have at least twice as much size, complexity, and risk as 2222? It does, so my estimate for 8888 should be 13 Story Points.

  8. Quickly come to a consensus and move on.

  9. Remember, this is Agile. You already know trying to predict the future is impossible, so spend your time and energy on delivering the software instead of arguing over an estimate that will probably be wrong anyway.

*- Virtually guaranteed. Any team with true Agile values will notice the improvement.

**- Also virtually a guarantee. You and your customer will enjoy the consistent casino-like sounds of money dropping into their piggy bank when you expect.