As teams begin to estimate User Stories, they may explore different approaches such as T-Shirt sizes and Fibonacci sequences that stop at 8 or go much higher.
This freedom to choose a relative sizing style allows a team to adopt what fits well within their work environment.
While this flexible approach is quite useful at the grass roots team level, it does pose an interesting challenge in the Enterprise setting where Agile teams roll up into an Agile PMO.
How do those in charge of the overall strategic planning, make informed cross team decisions with Product Backlogs of such varying size criteria? How can they identify the features that involve the least complexity, effort and doubt coupled with a high return on investment?
Before we go into my suggestions on how to address this, let’s explore a common fallacy that is being evangelized in the Enterprise today.
Mandating Story Points to Ideal Days Solves Cross Team Sizing Inconsistencies
“1 Story Point = 1 Ideal Day (6 hour work day)”
Seems quick and easy doesn’t it? Mandate that all of your Agile teams conform to this and your problem is solved!
By doing this, however, you’ve inadvertently stripped the Story Point of its original intent while roadblocking your team from personalizing (and humanizing) the process. You risk dismissing the conversations about complexity, effort and doubt while focusing on the mythical 6hr work day.
Another unintended side effect of tying Story Points to actual hours is that it isn’t long before people make the dangerous link between Story Points and Budget.
So what is the silver bullet to this issue? As is the case with all things Agile, there is no silver bullet! Solving this issue depends on the nature of the Agile teams and their relation to the business within the Enterprise.
Are these teams separate business units within the organization, or do they all contribute to the same product?
If the teams each have their own role within the organization and are only loosely tied to the same business goals, my suggestion is to let them be for the most part. Sizing, and especially Velocity, does not translate well across teams or up the organization. It will be an apples to oranges comparison, and you should keep your eye on delivering business value. As long as your teams are collaborating by sharing their Release Plans, does it really matter if they use a T-Shirt size or a Fibonacci scale as a means to an end?
If the teams do happen to roll up into an overall product, then I suggest that sizing occur from a single Product Backlog before decomposing them into each Team Backlog. With this approach, you can have the overall strategic conversations early. I would much rather have representatives from each team weigh in on a single Product Backlog, than try to make sense of it from the bottom up. This also brings a consistency to the sizing while allowing each team to have flexibility at the Sprint Planning level.
To summarize, tread carefully when trying to apply consistency across Agile teams within the Enterprise. It may not make sense to mandate sizing techniques, especially if it causes more harm than good.
I remember in a CSM class once we walked through the Dog Points Exercise. If you aren’t familiar with it, this seemingly harmless exercise typically appears as the CST wraps up his Story Point section. The class is split up into small groups and a list of dogs is projected onto the screen. The groups are given no instructions other than to classify the dogs. Some teams use color as their criteria, however I find that most teams use size. Each dog is compared to the next dog on the list, and grouped based on relative size. This should have been a straightforward exercise, however our CST decided to throw “Scooby Doo” in as a dog, and we spent the majority of our time arguing about his size due to Scooby’s 2 dimensional nature.
I’ve also seen coaches try to use the Pile of Dirt metaphor with horrendous results. At a basic level, envision multiple piles of dirt in a room. Why is there dirt in the room, who knows just pay attention. So depending on how many people you have to help, and how strong they are, what types of tools they have, it can take various amounts of time to move each pile. About the time you start deep diving into Joe has a teaspoon and Mike has a bulldozer your audience has most likely shut down their brains. Your dirt might as well have left on a train from Boston going 72mph to meet the other piles of dirt.
One exercise that is somewhat successful is the T-Shirt model. Everyone understands T-Shirts right? You imagine your Story Points falling into sizes such as XS, S, M, L & XL instead of numbers. This can be a rather useful method until they start applying the fibonacci scale to the sizes. Is M size a 2 or a 3, why isn’t there a 4? Please don’t ask me why there isn’t a 4. Dr Fibonacci was a deranged individual ok? Just write the T-Shirt Size to Point mapping on the wall so we’ll not forget it again during our next Release Planning Session.
Loading ...