Knowledge Transfer in Agile Teams using User Stories

In agile organizations, team members work together closely, and team members are highly specialized. But there is hardly any overlap of knowledge and skills between team members; it is basically a team of specialists… sound familiar?
In most teams, it is not possible to move work around. Only one or maximum two team members are able to implement the work planned. This often leads to stress in the team and results in not-done work items at the end of the Sprint.
Team members might be interested in learning and expanding their skillsets beyond their areas of specialization; but usually there is no time available.

T-shaped to the rescue

Line management is often interested in increasing the skillsets of their employees. The so-called T-shaped person refers to employees who not only increase their specialization, but also broaden their knowledge and skillsets to become generalizing specialists. There are two benefits to this approach: line management can apply employees’ knowledge and skills in a broader context and dependency on «Single Point of Failures» decreases. For employees, a wider knowledge base and skillset means increased market value and therefore a better market position.

Trying to broaden knowledge and skillsets with trainings can be a good starting point. Thereafter, it is critical that employees have a chance to gain practical experience to put the newly acquired skills to use. At this point, both line management and agile teams struggle to find sufficient time.

Knowledge Transfer is Work

As an Agile Coach, I ran into this problem about a year ago. After discussions with all parties involved, I came to the conclusion that knowledge transfer means «work». In an Agile Team, work is described as Backlog Items and can be planned in e.g., Sprints. So, why not create Backlog Items for knowledge transfer?

In Agile Requirements Engineering, we often make use of so-called «User Stories». A User Story describes a functionality or customer wish in general from the perspective of the user. It describes the goal and the value of a particular requirement and includes Acceptance Criteria. These Acceptance Criteria facilitate the acceptance by e.g., a Product Owner (PO) once the User Story is done.

A Knowledge Transfer User Story

A User Story is the ideal medium to describe exactly what needs to be done in the case of knowledge transfer. A User Story for knowledge transfer has a clear description about the goal and the value of the Item. It also comes with Acceptance Criteria, which makes it easy to check whether the knowledge transfer has been accomplished.

Once planned into a Sprint, the Knowledge Transfer User Story is divided into Tasks, where Tasks are shorter than one working day. In this way, the knowledge transfer can be planned in very small, controllable steps. Two people work on these Tasks: an experienced team member and a «trainee» or newer team member.

Example of a Knowledge Transfer User Story

As a team member I want to be able to configure file A,
so that I can release the module myself without any support from B.
Acceptance Criteria
- Configuration of file A without support
- Releasing the adapted configuration file with the adapted settings

How did this work in reality?

In a concrete customer case, the Product Owner and the line manager wrote a Feature for knowledge transfer in the team for the last part of the project. In this particular case it was necessary to transfer the knowledge of an external party (supplier) to the team. The goal was to ensure enough knowledge and skill to maintain the component (and to thereby remove the dependency on the external party). The knowledge transfer Feature was divided into a set of very specific knowledge transfer User Stories which were put into the Product Backlog.

For each Sprint, knowledge transfer User Stories were selected with the PO and the team. The knowledge transfer User Story was treated as a «normal» Backlog Item throughout the Sprint and the outcome was presented during the Sprint Review Meeting at the end of the Sprint.

Knowledge transfer emerged from the shadows and was promoted to «normal» work which found a place in the Product Backlog. The knowledge transfer User Story had an estimated size, a clear description and precise acceptance criteria.

The pros and the cons of this approach:

Pros:

Knowledge transfer became transparent and could be planned as «normal» work. The team liked this way of working, because knowledge transfer was no longer a hidden item that team members had to do «on the side». It also became clear for management that knowledge transfer has a cost.

Cons:

As soon as the team came under pressure, the knowledge transfer User Stories were put on the bottom of the Sprint Backlog or even thrown out. This is a typical reaction when teams are under pressure to deliver. However, after a while the knowledge transfer User Story re-gained importance, in this particular case because the cooperation with the external party had an explicit end date.

Was it worth it?

Generally speaking, applying User Stories to knowledge transfer works quite well. The main advantages are:

Full transparency about knowledge transfer (internal/external), no hidden work in the team
Full transparency for line management about who is broadening knowledge and skills
The goal and value of knowledge transfer are clear
Acceptance Criteria ensure that knowledge transfer User Stories have a defined scope and completion can be verified
Knowledge transfer User Stories have an initial estimation and priority
The importance of knowledge transfer can be compared to the other work items in the Backlog
The concrete amount and rate of knowledge transfer are now measurable

If you are interested in an agile way of working or using User Stories in your team, please do not hesitate to contact me or my colleagues in the Agile Unit of SwissQ.