Technical stories – are they included on the backlog?


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, 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.

7 thoughts on “Technical stories – are they included on the backlog?”

  1. I think this post actually touches on one of the (if not the) biggest weaknesses of the agile process. It frequently allows you to miss those critical tasks and design steps that might increase development efficiency or allow better scalability simply because they do not translate into comprehensible end-user stories.

    Recently at an agile conference, I heard the metaphor of the development of a house described in an agile way to illustrate the point of making sure that a product was thought of as a whole to ensure earlier functionality. It goes like this: Avoid building each component separately in sequence (eg. build the foundation, then the walls then the roof) because that way the product is not usable until entirely completed. Instead, start with basic usability and improve – so you would build a simple shack, add an extension, improve the walls and add an extra floor, install furniture etc, so the product is usable after each small step.

    Expanding the metaphor, the problem with this method is, that you are never ever going to build a skyscraper that way, and sometimes a skyscraper will be needed. The other problem is that as a technologist or developer you may clearly see the need for a skyscraper, but conveying this need to someone that doesn’t understand technology is extremely difficult. Also, trying to convert it into end-user stories is going to leave out all the critical details.

    I think the solution in cases like this might be some kind of hybrid method where the architecture required is identified and developed in separate projects (possibly managed in a none-agile way) with the usable features being prioritized and built on top using agile.

    I haven’t figured out exactly how this might work yet though.

  2. Putting technical stories on the backlog is a good way to make sure they never get done. Can’t really blame the PO for not understanding and thus not caring or not enough at least, they have their own sense of urgency.
    The effort and time needed to try and prove the value is best spend elsewhere (or put technicians in PO roles).

    What could be an option is to just have a fixed percentage time budget for technical issues. The team could then maintain a ‘technical improvement backlog’ of their own that doesn’t have to be seen by the PO; he/she may suggest to pick some of this backlog when the team finishes early during a sprint though.

    Even if the ‘TI’ time budget is small they could perhaps be allowed to save it up over a few sprints and then make use of it.

    Other option is just go for “encapsulation”, don’t mention it at all, don’t ask for permission, just do it.

  3. I agree that a technical story should not belong on the product backlog. But they should definitively be done somewhere. As a team we often use time we have left at the end of a sprint to do them or like Tungano said we do them them at the same time of another story if it seems relevant.

  4. I’m the PO on a fairly complex enterprise-level server-client authoring tool in the e-learning industry. In our team, technical stories are kept on the backlog. We believe it’s important that they should be, since it gives them visibility beyond just the technical team. Very often, if business is not aware of pressing technology needs, there will be no support to do them.

    By having the stories on the backlog, I am making stakeholders and non-technical people aware that they have to pay the piper. Fast-delivered features are not free – there is always technical debt to pay off. And often, by prioritizing a particular technical story, it enables us to pre-empt support issues. And support issues can derail sprints, so the less of those we have to deal with, the better. The value in actually tackling the technical stories transparently, is really that we are protecting our other sprint goals and over time continuing to build in quality in the product.

    But I don’t prioritize technical stories on my own. I do this in conjunction with the Scrum Master and one or more technical leads to ensure that I get the complete picture.

  5. Martiza makes a good point there. The end goal is a solution that satisfies user requirements and if these technical issues that are overlooked then they threaten the project. As they don’t have a technical story then it jeapordizes the process. Best to try and get it all out on the table first i think. I imagine this topic is going to run and run.

  6. Expanding the metaphor, the difficulty with this method is, that you are never ever feat to frame a skyscraper that way, and sometimes a skyscraper will be N10-004 required. The otherwise difficulty is that as a somebody or 642-902 developer you may understandably see the necessary for a skyscraper, but conveying this pasteurization to someone that doesn’t understand technology is extremely sticky. Also, trying to persuade it into end-user stories is 642-813 exploit to move out all the severe details.

  7. I think the option in situations like this might be some type of multiple strategy where the structure necessary is determined and designed in individual tasks (possibly maintained in a none-agile way) with the useful functions being prioritized and designed on top using nimble.Windshield Stickers

Leave a Reply

Your email address will not be published. Required fields are marked *