"Technical" User Stories

At Agile '07, Mike Cohn was posed with a question about how to estimate user stories with more accuracy. Specifically the question was trying to get Mike to address the problem with the technical debt at iteration start up such as setting up development and build environments. Mike's answers were pretty interesting but I cannot say that I was completely satisfied. I am not going pretend that what I am going to quote here is accurate because my recollection is a bit fuzzy at best (now that it is a few months later), but I am going to go ahead and give it a shot.

One approach was to define "technical" user stories, which I will clarify that he did not advocate and I am vehemently opposed to. One of the fundamental differences between traditional requirements gathering and user stories is how technical tasks and system architecture are "designed" because in traditional environments, conceptual and physical architecture related tasks are separated from the actual feature development. Decomposing a user story into smaller "technical" stories increases the probability that features are delivered late because of the muda and muri that occurs. This kind of thinking also runs contrary to XP because the user does not receive a direct benefit after the technical story is complete.

Here is an example of what I mean. Lets say you are getting started on a new project and you have to do stuff like, install PC's, set up an SCM, and a CI environment and you choose to go in the direction of writing up some "technical" user stories. One of the stories you might come up with would be, "as a developer, I want for the build to run automatically when I check in code to the source repository so that I know that the build is healthy". Sounds like a story doesn't it? You have a user, action, and goal right? Well, unless your customer is in the business of building continuous integration tools then the answer is not much! One may simply find enough user stories to fill up 2-3 iterations before the customers sees any of their stories actualized.

To mitigate this, "technical" story based teams will give customers the "power" to prioritize these technical stories. A customer might say "we can implement the... As a tester, I want to have a QA environment... story when we are actually ready to QA the app". Developers in this scenario allow the customers to build risk into the project rather than reduce it. This is because deployment issues are dealt with too late into the project and developers are required to "crunch" until they hack together some unmanageable scripts.

Another solution that MC explored was to adjust story points to reflect the "hidden" technical debt. This means that the first story pulled out of the backlog will receive an explicit point adjustment to reflect the debt associated with the starting up a project. I did not like this answer because it runs contrary to the whole idea behind using story points. They are not meant to be accurate at first because there are too many things we do not know or understand. The team does not have the benefit of historical information to know what their velocity is going to be. Just like on "whose line is it anyway?", the points don't matter!

In the end, what I recommend is to do something that will help everyone, which at our organization we refer to as "kicking the tires". During the first iteration of your project encourage your customer to select what the team feels is the high-risk-high-value stories. Dedicate some pairs to start spiking these stories because most of the time that is throw away code anyway. Get some other pairs working on infrastructure stuff like the SCM, test environments, IDE configurations.

At the end of this iteration, one will find that the velocity is really low because of the technical debt that the story had to pay. Do not let this number discourage the team! Accept the fact that we did not know what 8 points meant before we started but now we have a better idea. That is one of the reasons XP uses velocity and story points in the first place. Customers are generally pleased if you can do for them in two weeks what it once took them years to do. Focus on what the team has accomplished by delivering value almost immediately and encourage your customer to select another set of stories to work on, before you know it the team will know its velocity and really have a sense of what 8 points actually is.