One reader recently brought up the subject of using Story Points as a unit of measure for the "effort" or "duration" of a feature or capability, rather than estimating effort in days, weeks or months. You may have stumbled across this practice if you are following one of the variants of the Agile development movement.
For those of you that don't know what a Story Point is, it stems from another pillar of the Agile process. The idea is that you get users to describe use cases for the application they'd like (called "User Stories"), and they serve as specification of sorts. Story Points are used to quantify the effort (and indirectly, how long it will take to build). The point of all of this is to have some way of trading off one feature request against another. If you want a new feature that would cost 10 Story Points, you may need to drop 2 others at 5 points each. It's a "cost" system.
I'm not a big fan of this unit though, because I believe it's an unnecessary level of abstraction. There isn't any clear advantage that I can find in using a new abstract unit instead of just plain old days and weeks. The trading still happens the same way: "Want something that costs 10 days? Drop two others that cost 5 days each."
The danger to the stakeholder that's asking for the feature is that they're being forced to work in a unit they don't understand. It forces them to try to learn a new piece of jargon that seemingly hides what they REALLY want to know, which is: how long is that going to take? It seems extra odd to me because part of the Agile method is to try to bridge the gap between users and developers, which is why the whole "storyboarding" theme exists. But then turning around and using an abstract unit of measure for "effort" seems to be inconsistent with that, and actually clouds the topic of effort or duration. It seems to keep users in the dark about the "real" cost of a feature (time). Plus, the benefit of using real time units (days, weeks) is that stakeholders can see that development is actually a pretty slow and time consuming thing. Sometimes it really can take you 10 days to "just add a button". By using real units of time, you "expose" them to this reality.
What really makes my Spidey-sense tingle about an abstract unit of cost like Story Points, is that it's value relative to time changes with the wind. One month, each Story Point might be 3 calendar days. The next month, it might only be 1 day.
Another similar practice is to use "Pure Development Days" as the unit. This I like better, but still not completely. I like this better because it uses "days", which we all share some intuitive understanding of, but it's still a little abstract because of the built-in disclaimer: "Pure Development". What is Pure Development? Does it even exist? It's trying to demonstrate that over a period of 2 calendar days, you may only get to spend 1 day worth of development across those 2 calendar days, because of other things that come up that distract you from development. So, better, but still not quite there in my books.
The risk with Pure Development Days is that normal people will subconsciously drop the "Pure Development" and just think you're talking to them about regular old Days. Because that's all that coders do is code, right?
I do very much like the fact that with Pure Development Days you can derive a kind of productivity metric. Like, for every 3 days we get 1.5 days of solid development time, and 1.5 days of miscellaneous "admin".
For those of you who've read about my pet metrics of "Time Estimation Error" and "Distraction Rate", you may recognize that Pure Development Days is kind of like Distraction Rate, turned upside down. A Distraction Rate of 50% means that a developer spends half the time doing things unrelated to the core project (development), so if you want 1 solid day of development, it's going to take 2 calendar days. This is really a similar formula to Pure Development Days, but it flips things across the equals sign for good reason.
By using (plain old) days as the unit of measure for effort/duration, you can set expectations with stakeholders about when (on their calendar) they can have something, as well as the relative cost of something (2 features @ 5 days = 1 feature @ 10 days), so long as you're internally marking up your numbers for Time Estimation Error and Distraction Rates before quoting the bottom line to your stakeholders.
So, you internalize these fancy metrics inside the dev team, but get you speak plain english with your stakeholders, and still get the extra visibility into "productivity".
Comments