Increasing Transparency With Technical Stories

Stefan Döbrich
Transparenz erhöhen durch Technische Stories

Agile purists often believe that there are exactly two types of requirements in an agile organization – epics and user stories. It is easy to motivate that at least bug tickets should also be available. In this article I explain why it makes sense to look at technical stories in addition to user stories.

Dependencies and Transparency in User Stories

Let’s first look at what a user story is. In agile product development, a user story describes a customer’s requirements for the product. The focus here is on three essential things. These are the role in which the customer is as a user, the function to be implemented and the reason for the implementation request. The template for a user story is as follows:

As a role I want the feature, because of reason.

It is natural that these features often have interdependencies. So let’s look at the different types of dependencies between two user stories.

Initially, two user stories cannot have any dependencies. In this case, they can be discussed, evaluated and implemented independently of one another. In our example, these should be two stories, each with a complexity of five and eight story points.

two independent user stories with story point values five and eight
Fig. 1 - Two independent user stories

Of course, these user stories could also have a simple dependency on each other. In this case it is necessary to implement the user stories in a certain order. The team must take the dependency into account when planning. In our example, the story with five points must be implemented before the story with eight points.

two user stories with story point values five and eight, and one depends on the other
Fig. 2 - Two interdependent user stories

It is getting interesting now. The functionalities described in two user stories may overlap. In this case, the transparency of the backlog is at risk. While the two independent user stories have a total complexity of 13 points, it is not possible to make a definite statement about the complexity in the case of overlapping user stories. This is not a good thing and must be resolved through further refinement.

two overlapping user stories, with story point value five and eight - how big is the cut set?
Fig. 3 - Two overlapping user stories. How big is the cut set?

The part that is contained in both user stories is formulated as a separate requirement and the dependencies are made visible accordingly. In our example, there is a total complexity of 10 points for the decomposed and newly evaluated user stories.

the two stories are split into three stories, while one represents the cut set
Fig. 4 - Splitting the two stories into three stories

In practice, however, this case arises much less frequently for real user stories than for technical requirements. It happens significantly more often when infrastructure has to be created in deeper layers of the architecture, for example in the database layer. This new infrastructure then serves as the basis for the implementation of the actual user stories.

Introducing Technical Stories

Now let’s take a look at how to deal with such technical requirements. They cannot be formulated as a user story. For this reason, these requirements should be formulated as technical stories. These technical stories then depict the requirements for the technology of a product, which the customer is normally not interested in. As an additional benefit, technical debts can also be recorded in the form of technical stories and thus made transparent.

the cut set story represents the technical foundation of the other stories - a technical story
Fig. 5 - Technical stories as a task type for technical requirements

The outer form of a user story can be used to formulate a technical story. The tasks are then formulated from the perspective of the corresponding role of the developer. This not only makes it easier to refine the user stories accordingly, but also increases transparency.

As a developer role I want refactoring / database connection / etc, because of reason.

Increasing Transparency Through Technical Stories

A decisive advantage of using technical stories is the increased transparency in the development. Let’s start with a development team that only uses classic user stories and maps all tasks to these types of requirements.

a teams intransparent velocity chart over six Sprints, where user stories and technical debt cannot be differentiated
Fig. 6 - A non-transparent velocity chart

The diagram shows the team’s velocity over a period of six sprints after the start of a new product development. The velocity is stable and at first glance the team appears to be very productive. Based on this diagram, however, no statement can be made as to whether the team actually delivers functionality and added value to the customer. Since all tasks were recorded as user stories, it is not possible to say how much delivered functionality is in the total of the tasks completed.

a transparent velocity chart over six Sprint which shows the amount of technical stories involved
Fig. 7 - A transparent velocity chart over a period of six sprints

If we differentiate the stories into features that can be experienced by customers and technical requirements, the result is a clearer picture. Then it shows that the team had to create a lot of technical basics in the first two sprints. From sprint three, however, the proportion of user stories delivered continued to rise. In this way, the type of tasks the team is actually working on can be displayed very transparently. This makes it much easier to inspect the condition of the product and to make changes to the development in future planning rounds.

Tracking Technical Debt With Technical Stories

The added value of the increased transparency with regard to technical debts is most impressive. The diagram below shows the velocity of the seventh to ninth sprints. As we can see, this is constant. At first glance, the team delivers new added value for the customer at a consistently high speed.

a transparent velocity chart which shows the development of technical debt over nine Sprints
Fig. 8 - Tracking technical debt in the velocity chart over nine sprints

At second glance, the transparent presentation of the technical stories shows that the proportion of user stories in the implementation is declining again. This can be due to an increase in technical debts in the overall system. If this increase does not occur consciously and planned, the transparent representation of the technical velocity helps with the inspection and adaptation. Without a separation of the technical requirements, this would be much more difficult.

Final Thoughts

In summary, technical stories are a very good way to record requirements that are not directly related to customer benefit. This increases the transparency of the product backlog, since a clear distinction can be made between functional requirements and technical requirements or technical debt. Since technical debt should always be kept small, it is necessary that a qualified statement on the amount of known technical debt can be made. The reduction of this debt can also be actively monitored and planned.

Back to blog

Kanban Trainings bei AgileSkills

Team Kanban Practitioner

Regular price €600,00 EUR
Regular price €700,00 EUR Sale price €600,00 EUR
Zzgl. USt.

Kanban Systems Improvements

Regular price €1.200,00 EUR
Regular price €1.500,00 EUR Sale price €1.200,00 EUR
Zzgl. USt.

Kanban System Design

Regular price €1.200,00 EUR
Regular price €1.500,00 EUR Sale price €1.200,00 EUR
Zzgl. USt.

Aktuelle Artikel im Agile Blog

Throughput und Delivery Rate in Kanban Systemen

Throughput and Delivery Rate in Kanban Systems

Although the terms throughput and delivery rate are often used interchangeably, there are subtle differences between them. This article explains the exact difference between throughput...
Lead Time und Cycle Time in Kanban Systemen

Lead Time and Cycle Time in Kanban Systems

When discussing Kanban systems, the terms "lead time" and "cycle time" often come up. However, different people use these terms differently and sometimes they are...
Ein kurzer Leitfaden über Objectives und Key Results

A Beginners Guide to Objectives and Key Results

Objectives and Key Results (OKRs) is a goal-setting framework that helps organisations set clear, measurable goals. This article shows the definition of OKRs as well...