Technical Stories in Agile Software Development
I just read this interesting post on technical stories by Jack Milunsky. In the article he addresses the question of “Should technical stories appear on the product backlog for a Scrum project?” For billable client projects, a related question exists of “Are technical stores billable to the client?”
The answer to both of these questions is yes. Technical stories represent efforts necessary to improve the infrastructure of a system. While they do not add value to the system through the addition of new or refined functionality, they do directly add value to the system in other ways.
It is our responsibility to identify the value directly added by each technical story, and to educate the client on this value. It may not be as quantifiable as the value of new functionality, but it does exist. Better system stability, lower vulnerability to security or other malicious attacks, enhanced scalability and more robust disaster recovery all intrinsically add value to a system. Value can also come in the form of more efficient future development, and the associated reduction in cost or schedule.
In the article, Jack observes:
But what about the type of story asked by one of the members “As a development team member, I want the existing unit tests to run under CruiseControl, so that I know if anything breaks”. Where does this belong?
Well this is a perfectly written story but the story really has no ultimate value for the end user at least not directly.
I disagree with Jack that such a story does not have an ultimate value to the end user, or that it’s value is at most indirect. Automated unit tests allow the development team to deliver new features to the end user much faster. Every feature added to a system has a value, therefore the lack of any given feature has an opportunity cost. The direct benefit to the end user is the reduction of that opportunity cost.
If I am unable to articulate the direct value of a technical story to a client, I have no business doing that story let alone asking the client to pay for it. Effort without value is waste.
We include these infrastructure upgrade tasks in our project MMF workflow. Cards are written for them, and these cards are added to the project backlog. Once educated to their value, our clients are then empowered to make priority decisions between technical infrastructure tasks and new features. We must trust that the customer knows their business the best. They will know if the opportunity cost of a delay in the implementation of feature X is of higher value than the future cost and time savings of a conversion from Scriptaculous to JQuery, and will set the appropriate priorities.
About Dave Goerlich
Dave Goerlich is a Managing Partner at Designing Interactive. He is a software craftsman and lead architect for D-I's products and consulting clients. You can follow him on twitter at: @dgoerlich
4 Comments »
Search
Popular Posts
- 50 Tips To A User Friendly Website
- How to build a Gantt Chart with the Google Charts API
- My Favorite Pomodoro Timers
- Why Flash is Mostly Bad
- Why You Should Outsource Usability Testing
- Sharing the Grid
- The difference between User Research and Usability Testing?
- 10 Tips to Better Google Wave Conversations
- How to Label Submit Buttons
- Goals for 2009
Josh Walsh
It sounds as though you advocate billing the client directly for refactoring without any demonstrable added value. Is that true?
If refactoring would improve the development cycle of additional demonstrable features, then it shouldn’t be implemented until those features are needed.
Security holes are a different story. If we (the developers) discover a security exploit in our code, we should just fix it. There is no reason to notify the client of the exploit unless there are side effects they should know about. We do this all the time. If the client finds a vulnerability then it’s a bug from their perspective, which we don’t bill for.
Thoughts?
January 13, 2010
Jonathan Penn
Thanks for sharing your observations, Dave.
I don’t think I can disagree with the quote you shared from Jack, though. It sounds like you’re thinking of yourself as a customer of some theoretical dev firm. You, as an established developer, would of course find business value in learning about the unit tests from such a firm. I would expect an audit of these tests to be how you, specifically, would sign off on the stories.
But, I bet that none of DI’s clients would care about a story about “unit tests”. They want to know it works, of course, but “unit test” is the kind of phrase we should avoid with customers. They are the “eye glazing” phrases that distance us from their world and make us seem mystical.
The whole point of keeping close ties to the customer is to close that distance and to work hard to communicate on their terms at all costs.
January 13, 2010
Dave Goerlich
I’m specifically talking about efforts of a size large enough to warrant management equal to that of an MMF – something large enough to be broken down into multiple story cards. For example, updating a client’s application to work on a newer version of a development library or framework (Sandstone 2.0 to 4.0, Rails 1.x to Rails 2.x, .NET Framework 2.0 to 3.0, etc), or as Jack mentioned in his article – converting from MySQL to Oracle. Perhaps even the conversion of an application from one language to another (PHP to Ruby).
I mentioned security issues in this context – where the only available methodology for patching a hole in a framework might be upgrading to a newer version. The value to the customer here is the avoidance of the cost of compromised security. It’s our job to educate the customer of the true and accurate risks involved, the value of the completed task, and let them prioritize.
Of course, I would never advocate such infrastructure upgrade tasks simply for the sake of upgrade. There must be a definable value to the customer.
You are correct, bug fixes aren’t billable. Fundamental refactoring of code while working on it isn’t separately billable either – it’s simply part of the development process and is therefore “built in” to the points of each story.
January 14, 2010
Josh Walsh
Ok, I don’t think any of us are disagreeing. However, I think the term “technical story” means something more specific to me.
Technical stories, in my opinion, are cards which are non-demonstrable dependencies required to implement a feature that was requested. A task that the client didn’t request to be done, but is required to fulfill another needed task.
Example: The client may ask us to move from rails 2.2 to 2.3 to give them access to new capabilities. There will certainly be technical stories to upgrade rubygem dependencies, which would require technical stories to accomplish.
Intriguing post, I really enjoyed it.
January 14, 2010