The Five Hazards of Misusing “Technical Stories”

User Stories are a very common structure for populating product backlogs—but what do you do with the work that might not obviously be a “user” story? How should you handle backlog items when there will be no change to the user-interface? How should you plan for and deliver changes that will make the application faster, more scalable, or will make the application easier to modify?

Some teams call those type of changes “technical stories,” because there is a sense that they are not user-facing capabilities. While it makes sense that these are not as obviously user-facing, calling them technical stories can have unintended downsides to it, such as:

1. An implicit or explicit message that the Product Owner doesn’t need to be involved

When backlog items are called “user stories,” or the Product Backlog contains software defects to resolve, the Product Owner is clearly responsible for ordering the backlog to focus on value delivery. However, the introduction of a new type of backlog item, the “technical story,” can imply that the development team owns its prioritization; the term gets used in a way that says “Don’t worry about it, Product Owner. It’s technical.” In other words, “you wouldn’t understand.” But let’s be clear: The Product Owner is always responsible for development team prioritization—technical or non-technical stories.

2. The sense that it is not part of the team’s Sprint Goal

A Scrum team strives to meet a Sprint Goal every Sprint, and fixing defects and implementing new User Stories are elements of that Sprint Goal. However, “technical stories” can get set aside from that. When “technical stories” are separated from the rest of the Product Backlog, they take on a life of their own outside the team’s  Sprint Goal. The result can be the existence of an additional Sprint Goal, which at that point, it is no longer clear which goal is the most important to achieve. To avoid this problem, have a single sprint goal that includes all the team’s work.

3. The potential that the work does not have a defined set of acceptance criteria or definition of done

Because it is viewed as separate from other Product Backlog items, additional work becomes separated from the other good practices of the team: they can lose the clear definition of what it means to be done, and they can lose clarity of what tests must pass to validate the story. These backlog items can take on a life of their own, devouring more capacity than they are worth. Defining the acceptance criteria ensures that you stay focused on the most important capabilities.

4. Limiting visibility to the team’s capacity that is going toward that work

One of the three pillars of Scrum is transparency—and technical Stories that are delivered as a separate effort contradict this pillar of Scrum. When they are worked on apart from the rest of the backlog, they are excluded from the Sprint Review. The lost transparency limits the opportunities for inspection and adaptation, which are the other two pillars of Scrum. To prevent throwing off the balance of the pillars, always make transparency—particularly with technical stories—a top priority.

5. Fostering teams based on individual technologies, versus cross-functional teams

In situations where Technical Stories become the norm, and not the exception, they can impact the formation of teams; if the primary focus is delivering Technical Stories, then the organization may create teams that are formed around specific technologies. This type of structure creates additional interdependencies between teams, and additional dependencies make it difficult to deliver a product increment each sprint. Instead, focus on fostering cross-functional teams, to reduce the number of interdependencies and ensure a common goal.

If you are using the term Technical Story, and avoiding all the pitfalls I mention, carry on. If, however, you find yourself encountering the risks that I mentioned above, please drop the term “Technical Story.” Instead, simply refer to them as Product Backlog Items (PBI). And, like User Stories, work to make sure that each PBI has the following attributes:

• Value that the team and stakeholders can understand
• Is prioritized by the Product Owner amongst all the other backlog items
• Clear acceptance criteria
• Demonstrable value
• Is listed in the Product Backlog
• Is part of the work that the whole team is doing

Does your team handle “technical stories?” If so, what are they used for?