Running a business requires working with people with various skills, backgrounds, and perspectives. This mix of viewpoints provides a good push-and-pull that often leads to fresh insight for the product or business. It also creates challenges. People disagree. They see problems differently. They have trouble communicating. Managers often need to navigate conflict between people on their team.
It’s not uncommon for software development teams to deal with these conflicts. One way to bridge the different perspectives between product and engineering team members is to employ the user story.
Teresa Torres in her fantastic article User Stories are Better than PRDs says: “a product manager has a wealth of customer knowledge, an engineer has a wealth of technical know-how, a user story allows a product manager to communicate bite-sized knowledge about the customer to the engineer, within the context of what they are building.”
In this article, learn how product managers and engineers–or any business leader and his or her team–can express knowledge and foster communication by employing a user story.
SEE: User stories: The starting point in agile development
The product manager and engineers: What are their roles?
On a Scrum Agile team, the product manager is the voice of the customer and bridges the communication gaps between the team and the business’s many stakeholders. He or she understands the customer’s problems and needs, and vets the best solutions to those problems.
One of the most crucial parts of this job is collaborating with engineers to effectively implement the solutions that will provide the most value for customers.
SEE: Agile development: Cheat Sheet
What is a user story?
A user story is an artifact describing that an agent (the who) wants to do a specific action (the what) for a specific purpose (the why). It also specifies what steps are required to show or measure that the action has happened (the how).
User stories are prioritized in a product backlog; these units of work include everything that must be done to successfully deliver a viable product. Though the product manager usually sets up the first sets of requirements, the team collectively writes the stories they’ll work on during the cycle, estimates the amount of work each story will require, and collaborates closely to complete the work.
Examples of user stories (who, what, why, how)
User stories help engineers keep the context of what they’re building in mind–and understand for whom they’re building this functionality. These units of work are written in the following format: As an actor (who) I can do an action (what) for the following benefit (why). Let’s look at examples.
User stories: The who, what, why
First, the actor (the who). The actor tells the engineers who will be using the functionality. Here are three examples.
- As a freelance editor …
- As a distance runner …
- As someone who cannot attend an event …
Next, let’s look at the action (the what). This tells the engineers what functionality is needed.
- I can count the words in my article …
- I can listen to music offline …
- I can view photos of the event in real-time …
Now, the benefit (the why). This gives the engineers context, tells them why they’re building what they’re building, and reminds them that an actor has a need or a problem to be solved.
- So that I can send an invoice to an editor based off word count
- So I can run on trails without music cutting out
- So I don’t feel left out of what’s going on
In each of these examples, a specific actor wants to do a specific action for a specific purpose. These user stories help the team understand the context for the work they’re doing, as well as retain empathy for the actor they’re building the functionality for.
User story acceptance criteria: The how
User stories not only express the who, what, and why, but also note acceptance criteria, or the criteria for how success for the unit of work will be measured (the how).
For instance, if a product manager is specifying that a freelance editor needs a word count, the product manager needs to specify what counts as a word. Do articles such as a/an count as words? How about punctuation? How about links?
Acceptance criteria are often what bring up the most discussion between product and engineering. Collaborating on acceptance criteria ensures that the product manager and engineers agree on the who, what, why, and how of a unit of work. It also ensures that both sides agree that the engineers have all the information they need to work on a piece of functionality that will truly provide value for the customer.
SEE: Research: The rise of agile IT (Tech Pro Research)
How businesses can apply user stories to improve communication
The following steps are suggestions for how you might employ user stories.
- Understand your customers’ needs so that you can best prioritize the product feature, service, etc. that will provide value for them, and, in effect, for your business. Related: Create and sustain a customer focus within projects
- Brainstorm all of the tasks to be completed to provide that product feature, service, etc. Tip: Work with your team to compose this list.
- Write the user story for each task. Who will be performing this task, what will they be doing, and why do they want to do it? Tip: Keep your stories simple and concise so they can be finished in a short amount of time.
- Write acceptance criteria for each task. How will you measure that the user story actually provides value?
- Discuss the tasks, user stories, and acceptance criteria with your team. Allow room for conversation and for changing tasks, fleshing out user stories, and changing acceptance criteria.
- Determine a timeframe in which to finish the tasks. Tip: Try two weeks.
- Prioritize the tasks from most important to least important.
- Start working through the tasks from top to bottom.
Remember, a user story is not meant to be set in stone. Because user stories are objects to further communication between you and your team, they are malleable until the time the team starts work on them.