Technical stories - are they included on the backlog?

January 11, 2010 by Jack Milunsky

Introduction

If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.

The question

The underlying question the team debated was should technical stories appear on the backlog.

If they are on the backlog, it means the technical stories are to be prioritized by the PO. This may not be such a good idea considering that PO's are generally going to be biased towards prioritizing features and functionality over technical stories. Examples given were "Installing Cruise Control", upgrading DB from MySQL to Oracle, Setting up VMWare etc. Most thought leaders on the forum argued that technical stories should not appear on the backlog, overwhelmingly so in fact. But some rightfully point out that all work requiring development resources should appear on the backlog.

What does Scrum say?

If you take a look at the definition from the Scrum Guide on Scrum.org, it states:

"The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases."

"The Sprint Backlog consists of the tasks the Team performs to turn Product Backlog items into a “done” increment. Many are developed during the Sprint Planning Meeting. It is all of the work that the Team identifies as necessary to meet the Sprint goal."

So what's the right answer?

Well, my answer is it depends and it depends on the context. For example, if your definition of done includes unit tests, automated tests etc then these work items don't need to be specific items on a backlog. This is stuff that gets done by the development team and there is no negotiation. Estimates need to include the time required to complete all of these elements of the definition of done.

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. In this particular case I'd therefore suggest the following:

This type of story definitely doesn't belong on the product backlog but would be a perfect task that could exist on the Sprint backlog assuming you're tracking tasks. I am still in the Scrum camp on task breakdown as opposed to the XP folks who prefer to work just at the story level. If you're doing task level breakdown during the sprint planning meeting then this type of Story or work could exist on the Sprint Backlog as a task and the time associated with doing this can be tracked on the burndown. Most XP folks will say this is just micro-managing all over again.

To quote Ron Jefferies: "Technical stories have been found to be an inferior idea by many practitioners who have tried both ways. I don't know of a single one who would go back." Now Ron is a really smart guy and has ton's of experience and it's hard to argue against his opinions or any of the other smart folks on that forum.

In conclusion

I suggest you decide how to handle this as a team and do what you (the team) think is best. I will state however that the XP folks appear to be the most progressive in forging new ground in agile efficiencies and techniques so watch what they say carefully and even consider what they say.

Permalink