Technical communicators are often called upon to support multiple development teams; it’s rare for every team to have a dedicated Technical Communicator (TC). To deal with this, writers on a high-functioning TC team need to be able to take on stories for sometimes unfamiliar products and technologies, avoiding silos of expertise in favor of flexibility. Inadequate user story writing leads to confusion and delays work completion.
Well-written user stories help TC teams achieve that flexibility, manage scope, and get work done more quickly. Agile provides an excellent framework for writing user stories. It is an iterative approach, most commonly associated with software delivery, that builds a project incrementally from the start instead of delivering everything all at once near the end. It’s a way to respond to change in an uncertain environment by breaking down projects into smaller pieces of user functionality called user stories.
However, user stories for tech comm require a different approach than traditional developer user stories. When my technical communication team first adopted agile, we didn’t know how we would apply the methodology to our team. As a result, our user stories were basic descriptions of what the writer needed to do, often reiterating the stakeholder’s request but not providing sufficient clarity or background for implementation. For example, one early user story went as follows:
- A document exists that provides a high-level overview of Product Name, describing what it is, what it can and cannot do, and enumerating the risks.
- Users understand what they need to know about Product Name at a high level as the result of reading the document.
As the example illustrates, our user stories started out more task-focused and only included acceptance criteria. We focused too much on what was asked of us to do and not on the user and their problems. In addition, we were also assigning ourselves the stories we wrote. So it was hard for team members who were either new or did not know the product and the subject matter experts really well to pick up any stories they did not write themselves.
User stories are supposed to consist of a user story or a sentence that tells who the user is, what they can do with the feature, and the benefits, as well as acceptance criteria. The format of the user story is broken up into three parts:
- As a (audience)
- I want to (goal or action)
- So that (business value).
To walk through the individual parts of a user story, a scenario could be to document a new feature of Product A. Since Cengage is an educational technology company, a new feature could be a new course creation process for Product A. So in order to document the feature, the first step is to know who the users are.
The first part of the user story identifies the user. So regarding the scenario of a new course creation process, at Cengage the main user for this feature would-be instructors. Sometimes there are different types of main users for a feature or product. For example, at Cengage there are two main instructor users: a Cengage instructor and a learning management system (LMS) instructor. So the first part or the “as a” part of the user story could be, as a Cengage Instructor or as an LMS instructor.
The second part of the user story, “I want to” should refer to the goal the user is trying to achieve, not what the feature does. Referring back to the scenario about documenting a new course creation process for Product A the user goal would be to set up a course. So the “I want to” or user goal for the story would be I want information on how to set up a course.
The final part of the user story is stating the business value and how the feature benefits the user. If there are corresponding developer tickets, then the business values should be pretty similar if not the same. One possible business value of the scenario would be instructors being able to teach their class. So one possible user story for the scenario of documenting a new course creation process for Product A would be: as a Cengage instructor I want information on how to set up a course, so that I can teach my classes.
After the user story is written, the next step is to add acceptance criteria to the story. Acceptance criteria are how you confirm you have actually achieved something. They establish a shared understanding and are typically a set of easy to understand statements with a yes or no answer. In order to write acceptance criteria, you need to know both your user and the product/feature well. Writing acceptance criteria should be a joint effort between the team and the product owner. For example, the entire user story for the scenario of documenting a new course creation process for Product A would be:
- As a Cengage instructor, I want information on how to set up a course, so that I can teach my classes.
- Acceptance Criteria:
- I have information on how to do the following:
- Create a course
- Create sections for my course
- Add instructors and teaching assistants
- Add textbook(s) to my classes
- I have information on how to do the following:
Writing effective user stories takes practice especially if you are not accustomed to thinking in an agile mindset. The three most important points are: know who your user is, what they want to accomplish (goals) when using a new product or feature, and why. Write out the user story first before adding acceptance criteria. The user story is designed to get you thinking in the mindset of the user so you can write out the acceptance criteria. The acceptance criteria are simple easy to understand statements that can be answered with a yes or no and are how you know you have achieved something. Writing out user stories can help organize a large project into smaller more manageable pieces of work for one or multiple writers to work on.