This article is one about certainties. And also uncertainties. We all know the certainties of life, foremost of which is death. In a civilized society, taxes are inevitable, and in corporate America, the painful process of obtaining and providing estimates is inevitable. Although I'll describe estimates concerning information technology projects in an Agile organization, I'll narrow my focus on the uncertainties of estimating user stories by using man-hours or story points.
My perspective is that of an Agile coach with 15 years of software development, team management, and project management under my belt. Despite this broad experience, I still find myself on the fence about implementing user story estimation. The IT and Agile communities at large appear to fall into one camp or the other, or are noncommittal and claim to "just do what works for you" when considering whether to apply points or hours. As an Agile coach, teams look to me for direction, and being on the fence is not where I should be. So I've embarked on a journey of discovery to find out where I actually stand.
On the one hand, I have found myself not liking story points for estimating user stories, for several reasons. Business units just don't understand the story point concept, and it is quite a cultural battle to engage in. There's often gnashing of teeth, wringing of hands, and patronizing attitudes when getting buy-in from the team (read: business product owner) on using story points. Even after training, you still may not get buy-in, especially when the organization's budgets for projects are based on time-to-deliver projections. You can't get around the ideas that "Time is money" and "Tell me how long it will take so I can fund the project." Therefore, business units love man-hour estimates.
founding member Mike Cohn of Mountain Goat Software drives home this point: "So, story points are about time -- the effort involved in doing something. Because our bosses, clients, and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty, and complexity are factors that may influence the effort involved."
This has me asking, "If story points are about time, and business units are familiar with man-hours representing time, why not just estimate user stories in man-hours instead of using the story point abstraction?" And there is the side of the fence that says user stories should be estimated with man-hours to keep it simple for everyone involved.
On the other side of the fence, delivery teams seem to gravitate toward story points, and for good reason. Story points provide an abstraction layer that is geared toward getting business units out of the mindset of expecting accuracy in man-hour estimates and into holding team members accountable for "bad" estimates. "All estimates are bad," I say, as they are rarely accurate. They are rarely accurate because no one can predict the future and all the change it may bring. Story points are T-shirt-sized estimates best used in backlog grooming, not indicators of "how long."
So where is one to stand when "time is money" and they need to know "how long will it take" because the money demands to know? One way might be to use story points to estimate T-shirt sizes for user stories and rely on subtasks to know when
. Could this be the way to provide something palatable to both the delivery team and the product owner? I'm still on the fence, so I continue.
To further study the question, we start with the case for story points, and one of the core reasons for the existence of the practice, as quoted from a discussion
on a popular technical site, StackExchange:
Hours have an implied precision and tend to be looked at as 100% accurate, all humans understand what an hour is so if you say 10 hours it must be ten hours. To compensate for this the person estimating will build in some "extra time" to compensate for the unknowns. It is just human nature they don't want to be held accountable for an estimate when they didn't have all the data needed.
The problem with this is the larger the task/story the greater the complexity and the more time it would take to develop a truly accurate estimate. At some point it is just not worth the effort. Especially when you are looking at work that will not be done for several months.
Points on the other hand have an "acceptable" implied imprecision since they are relative only to each other.
By using the Fibonacci series: 1, 2, 3, 5, 8, 13, etc., the team is able to compensate for both the complexity of a project and the expected effort. As the numbers get larger the fuzziness of the estimate is built in. Time is not wasted trying to determine if it is a 9 or 10 or 11, if it is larger than what the team calls an 8 and smaller than what the team calls a 20 then it is a 13. As the story gets closer to being accepted into an iteration it is further broken down and refined and the accuracy of the estimate improves.
By using this method the near-term work can be estimated with a high degree of confidence, the further out you go on the schedule the confidence drops, but the team still has a good idea of the effort involved without spending an inordinate amount of time braking down a story that may never be done due to changing priorities.
And in that same discussion comes a thought that tips me to the side of man-hour estimates, which essentially boils it down to management culture and trust:
Points add an abstraction away from time for psychological reasons, implicitly to prevent programmer burnout. Somebody still has to turn the abstraction into a time/financial cost. It just passes up the chain until somebody is willing to take responsibility for it.
My own view is that programmer burnout is not caused by attempting to estimate in time, it's caused by inappropriate management reactions when things take longer than expected.
If you're making up abstractions to avoid giving a commercially useful estimate because you fear punishment that much, the problem is with your management culture.
It's better to have a supportive environment where sincere and hard working people are understood to make some mistakes, but where's there's transparent feedback, rather than adding layers of abstraction so they don't have to confront realities like 'I thought this would take a day and it's taken over a week'. To my mind, that's treating engineers like children.
I believe these challenges in estimation are one of several reasons for the prevailing attitude around Agile that it just doesn't work quite as well for a large, matrixed organization. Larger organizations tend to have layers of program and financial management that make things like story point estimation challenging to adopt at best. Even if the practice is accepted, interested parties will quickly begin to sum up subtasks and equate a story point value with a mapped man-hour sum from its subtasks. Why bother fighting this psychology?
So back to the fence that I was sitting on. I think the answer came to me after discussions with several peers and, specifically, with a mentor and a director on my team. That answer is to know the layers of the organization that the team is beholden to, and from that, decide whether story point estimates will work. A smaller, independent team may likely be able to run more efficiently with story point estimates, while another may not be afforded that flexibility and man-hour estimates will be more acceptable. The answer truly is to "just do what works for you."
Further, I find that teams new to adopting Agile methods such as Scrum can get up and running faster without having to wrap the team and stakeholder's minds around story points. Although I think it is a short-term solution to get up and running with one less hurdle, it does lend itself to KISS (Keep It Simple Stupid) by sparing everyone having to learn the how
of story point estimation.
Given most corporate climates, I can say that I've not-so-safely landed on the man-hour estimation side of the fence. This is not to say that I am entirely happy about this landing and would actually rather use story points. But I do believe that when waging war against traditional project management, estimation, and budgeting practices, this is one I will often opt not to fight. More power to you if you do, and I'd support that decision.
Ultimately, I'd rather advocate that even when sticking to man-hour estimates, stakeholders understand the word by its definition and plan accordingly. If we can get a more trusting and honest understanding of what an estimate is and is not by all parties involved, then the whole story points and man-hour debate is less important anyway.
To all my peers in the Agile community who may read this, please understand my perspective. I merely wrote this article to document my thought process regarding what I will recommend to teams for my current employer. This employer's business culture heavily influences that recommendation. However, I do feel it has value for those coaches who are considering different approaches to story estimation for various teams. Your situation may be different, and this "hours versus points" article is less valuable because you can safely do one or the other. However, I do look forward to further supporting arguments in the Comments section.
Photo source: http://www.google.com/imgres?imgurl=http://cp91279.biography.com/Bio_Mini-Bios_Yogi-Berra_SF_HD_768x432-16x9.jpg&imgrefurl=http://www.biography.com/people/yogi-berra-9210325&h=432&w=768&tbnid=r9TtQ3OOai9aNM:&zoom=1&docid=_a1rJULsx0MSJM&ei=F1mIVfLhA8XSoASV1Y7oCQ&tbm=isch&ved=0CDgQMygQMBA
Agile Estimation Techniques
Why Sprints Should be Planned with Hours, Not Points
Why use story points instead of hours for estimating?
Story Points Are Still About Effort