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.

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.

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.

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.

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?