Step into my web said the spider to the fly!
User stories are a framework to describe who needs a piece of functionality, the goal of the piece of functionality and the benefit that the “who” part of the equation expects. The user story does not define how that goal will be attained or every step. Every user story is a combination of a card, conversation, and confirmation (Ron Jefferies’ 3 Cs). It is a lightweight path to getting a piece of work done. That piece of work can be a new user interface or a problem processing batch transactions. If you are going to adopt user stories for legacy or maintenance work begin with these four steps!
- Agree on a definition and approach for user stories across the flow work. There are numerous user story frameworks. I am partial to the Persona, Goal, Benefit approach, but there are others. Agree that everyone in the flow of work will begin using user stories to talk about the work. Conflicting frameworks will cause confusion and frustration.
- Create a set of personas that both technical and business personnel will use as they craft user stories. One of the reasons people resist users stories is the difficulty identifying a human persona in attach to the goal and benefit – instead of asking someone to create a list run, an interactive workshop with a cross-functional team to generate a list of personas. User stories are an invitation to a conversation; that conversation can begin with a discussion of who the application serves as an activity. Creating a set of personas for a legacy application and then applying those personas to user stories is a great learning experience. When support for a legacy application is outsourced, developing a set of personas is an excellent exercise to jump-start the transitioning the application.
- Pilot the user story approach using paper and pencil. Jumping directly to tools can cause all sorts of teething problems. All tools have their own opinion on how work should flow. That opinion is built into how the fields are named as well as the order in which events happen (opening, completing and changing status for example). Even if the tool matches exactly how you want to work, waiting for the paperwork to wind its way through purchasing can dampen a lot of enthusiasm.
- Once you are comfortable with the process, buy a tool. Adopting a work management system such as Jira or VersionOne that will be used by the product and development communities. A common tool will help to use and adopt both a common process and a common language. A common tool topped will support developing a common language in which user stories play a role in implementing cross-team communication.
All four steps require two very significant upfront decisions. The first is that you are going to use user stories. Implicit in that decision is the decision to use an agile approach to delivering work. Agile is technology or code base agnostic; however, making the decision to stop using tried and trues methods and to SHIFT your mindset instead will be hard. Everyone involved in using user stories will have to expend effort to change how they work and think. Second, if you are going to use user stories (or agile) everyone involved will need some level of training. This will be compounded as soon as tools are involved. Train user stories and agile separately from the tool.