Getting better at our pointing game...

“Said the straight man to the late man

Where have you been?

I've been here and I've been there

And I've been in between”

I Talk to the Wind (King Crimson)

Sometimes when I coach teams and try to get a sense of the rationale behind their rough relative sizing of stories, I get a myriad of responses spanning from complete guestimation, all the way to precision to the sub-atomic level. Scrum is very open to techniques for assessing the points of a story, and although precision is never our goal – neither are fantasy and dust in the wind (wait, that’s another song). 

It really all comes down to the “in between”.

There’s a marvelous quote by Charles Dudley Warner an American essayist, novelist, and friend of Mark Twain that goes something like this:

 “There is no such thing as absolute value in this world. You can only estimate what a thing is worth to you.”   -- Charles Dudley Warner

When we think of our Agile teams and the practice of story estimation, Mr. Warner has definitely hit on a hidden truth. So often people come aboard the Agile train in hopes of some mysterious enlightenment or gaining some sense of security. Security in believing that Agile promises a sure-fired way to encapsulate the degree of effort around a story by injecting its mathematical voodoo into the cauldron. We all know that this magic does not exist but still must agree that some form of pseudo-science is worthy of our consideration. Heck that’s why things like Fibonacci numbers excite us so, right?

As a professor once said to his class, “Surrounding every kernel of objectivity is the shell of subjectivity”. There’s always this constant battle of how we get to that “precision” - we so dearly want in our lives - when we’re surrounded by people with jumbled judgments and dissimilar approaches - not to mention that java coder who fancies wearing Spock ears to work. With all this noise and contention how do we arrive at that “in between”?

Let’s lay aside the standard Scrum technique of Planning Poker. We all know how PP works. Triangulate your estimate by reviewing effort, complexity, what we know, what we don’t know, and risk. Ultimately placing a value on it after comparing and debating the lowest and highest estimates. And of course we do this by probing the different parties, encouraging them to explain how they came up with their numbers. 

Some great thinking comes out of a simple process like this. For now though, I’d like to describe another technique that I’ve found helpful for teams in arriving at estimates by applying a more calculative method. This works great for those super-duper engineering teams who love to play with numbers - they just "want their Pii and eat it too!"

And please, before you start sending me all that hate-mail - this does not diminish the value of Planning Poker by any means. PP still works great for many teams; but if you’re the type of Agile team that constantly suffers from stories under or over-estimated, missed details or just want to apply a method that adds a bit more sanity to the insane ambiguity we’re all faced with, try this. It’s called the Elatta Method (using Complexity Buckets). If you want to catch the entire webinar from Sally Elatta just click here. She gives a wonderful tutorial on Scrum, with a thorough discussion on some basic estimating techniques.

I must apologize to Sally upfront. I have deviated from her original approach somewhat but simply to make it more adaptive for teams applying a scaled agile method like SAFe. 

Anyway it goes something like this:

When preparing for and executing your Story Grooming session:

1. As a team, decide on the appropriate Complexity Buckets best suited for the type of work you’ll be doing. Take into account the type of stories you’ll be estimating. For example, the kinds of buckets you might see are Analysis, UI/Interface, Business Logic (Code), Testing, Integration, Configuration and Deployment. There’s no finite set so you can add and subtract from what I’ve listed. You may think that the list given resembles an almost waterfall-like SDLC. Well in some ways it does but that’s okay, because however you look at it - the team still needs to consider the path or technical disciplines it must cross to deliver a solution (via the effort involved to do the work.)
2. During your grooming session review each story through each Complexity Bucket lens, applying the appropriate values you feel that bucket will require. In pure Elatta we use values like Low=1, Medium=2, High=3, and Extremely Complex=4, but in my experience I found using Fibonacci’s 1, 2, 3, 5, and 8 respectively, works best. Or as I’ll suggest in a moment, which really worked well with my teams, was to forego the arbitrary integers for estimated hours. Yes it’s almost like super-high level tasking, but hey, engineers seem comfortable thinking that way. Just keep it high level and don’t let them get dragged down into every nook and cranny.
3. After you’ve run through your deck of stories, estimating time for each bucket, add up the hours across the Complexity Buckets and divide by 8 (for the number of hours in a work day).
4. This will result in a number that can be rounded up to its Fibonacci equivalent.

 Complexity Bucket Samples:

The examples above are just some sample buckets I’ve used in the past. Again, they can be tailored by the teams to best represent the work that is planned. 

Below is a screenshot of a simple Excel calculator I use during my grooming sessions to help derive my final story point estimates. If you’re interested, email me and I can send you the actual spreadsheet with calculations.

The FINAL Points are entered by you manually, rounding up from the Point Adjusted column to stay within the Fibonacci sequence. This technique also enables you to see immediately if your estimate extends beyond the SAFe 8-point story sprint limit (or any other boundary you may have established) so that if splitting is necessary you know so before committing to a story too large for the iteration. 

Most important to remember…this is not a one-person activity. Its true purpose is to help our teams focus on what’s really important in the story. In some cases, it may even help us better articulate our Acceptance Criteria.

Let me know how this works for you. It might be interesting to go in with the point estimates you initially gave your stories during backlog grooming and see how the original points compare to the results using this technique. 

In the long run it’s all about helping our teams become better at estimating their stories so that our commitments become more reliable and our customers can gain an even greater confidence in the teams building their products.

And remember – “There is nothing to winning, really. That is, if you happen to be blessed with a keen eye, an agile mind, and no scruples whatsoever.”

 John