Technical User Stories

User stories are a very important part of agile development, but there is another type of user story that is just as important and is used to supplement user stories. That is the Technical User Story. A Technical User Story is focused on the non-functional support of a system. Examples of this may include security or performance, or scalability and architectural work. All of these and more fall outside the realm of the user stories and there for need the technical stories when developing them.

A major difference between user stories and technical stories is that a user story is focused around functional descriptions of the behavior of a system. Technical User Stories however are used to support the upper level behavior of the system and so are often also call infrastructural stories. The Technical user stories help to prevent overloading of a user story by taking the load of the basic infrastructure off the user stories. Otherwise user stories would be much longer.

Technical User Stories can be easily forgotten when there is a backlog of maintenance activities. It is easier to focus of functionality and to ignore the technical infrastructure or push it back until much later. A way to bring user stories to the forefront is to perform a story brainstorming workshop as well as an end to end release plan. The end to end release plan helps you to see the who project and this way can bring out the technical stories. Another way to figure out what you would need for your technical stories is to look at the acceptance criteria.

There are five basic technical stories that you should be able to identify: Product Infrastructure, Team Infrastructure, Refactoring, Bug Fixing, and Spikes. Product infrastructure are stories that directly support the functional stories. They could be infrastructure that has to be newly created or molded around the function. Team Infrastructure are stories that help to support the team and helps them to deliver the software. Refactoring are simply stories that focus around areas that a refactoring candidate, whether they are code, design, automation tools, or process documentation. Bug fixing are clusters of bugs that would increase repair time or decrease testing time. These stories are more for efficiency. And finally spikes are stories that are more prototype code over actual documentation, and are created when the storied or design calls for them to make the functional requirements be met.

While it is not necessary to have to separate the user stories and technical stories into separate groups, it is important that you and your team know that there is more to writing user stories then just focusing on the functional aspects of the project, and that they are prepared to meet these challenges when they are faced with them.