What Is Agile Story Writing?
Photo @josefandiaz
How To Create Story Maps And Write User Stories With Confidence
By Lenka Davis
Are you a nontechnical entrepreneur that is building a technical product? Or are you someone who has heard about Agile story writing and wants to know more about what they are? Have you been asked to help write User Stories?
There are many reasons a product owner hesitates to build a Story Map and write User Stories. They may have already provided the information or descriptions of what they want. The difficulty of putting the whole story into the Story Map and User Story format may compel them to have another team member complete this task.
There are a lot of different ways of writing stories and creating maps, it all depends on what you are trying to build. Also, a pair of team members can write user stories successfully. This works well if one of them knows the product and the marketplace, and the other has experience writing stories. There is no wrong way to write these, it’s more important to get started.
Topics
What is Story Writing?
Story Map
User Story
Maybe you are a human resources expert building an AI tool that helps people stay healthy, or a teacher creating a reading tool that helps kids with learning differences learn to read. There are many nontechnical professionals, such as lawyers, doctors and creatives, in the business world building technology solutions because they have found areas where they can solve a problem or help their users or clients. No matter what your expertise is, in almost all cases you will have to explain your solution to a technical team. These discussions will inevitably lead to Story Writing which includes creating a Story Map and writing User Stories.
What is Story Writing?
Basically, story writing is the written and visual (via a map) documentation of what the product will do, broken out into smaller tasks, explained in a story format. Story writing includes these three parts:
A Story Map
Epics or Epic Stories
User Stories
The Story Map is a big picture of the service or product and the User stories are just the beginning of a conversation with the team building the product.
Detailed definitions of the parts are listed below and you can use only those that apply to your product or service.
Some concerns product owners or development teams have about writing stories is that they are still trying to figure out how everything will work together. This could be any part of the product including what the user interface or user experience (UI/UX) will look like, the technology used or what a user will have control over or not, the list is endless.
For example, if you are really clear on the overall workflow of your product, but not sure how each team or user will be using the final application then start with the part you know. Building a story map and writing user stories can take a long or a short time depending on what phase of your business you are in. Some projects take three to four months with four hours of meetings each week with a small team. Some take a couple of weeks to write up the stories for an MVP (minimum viable product).
A small team is the best option to work on this because it keeps the conversations manageable. It consists of five people or less and includes at least the product owner to describe what they want built, a member or two of the software development team to help guide the technical conversation, and a project manager to help keep the project on track.
Story Map
As you would write an outline for a written article or book the story map acts the same guide.
A Story Map has these features:
A grid-like representation of epic(s)s and stories in sequence order based on their business value and the order the Agile team decides to release the features
Usually on a white board or paper with different colored stickies
Ordered from left to right in the order of the steps or process needed
Viewed from top to bottom in the order of the initial to more detailed features
“Building a user story map helps us focus on the big picture – the product as a whole instead of getting myopically focused on an individual story.”
Above is a story map example from a popular post.
Think of the story map parts as the human body, where a backbone, the body and ability to do activities are all part of the body.
Backbone - a list of the minimum set of capabilities or features. These can be turned into Epics (Epic stories) and usually become the MVP (minimum viable product), the first release of the product.
Walking Skeleton - the main body of capabilities or features based off of the backbone. Without any of these the product will not work.
Activities - The tasks or sub tasks, written in user story format, that describe what the product or service can do. Used by the development team to build the product.
Backbone, walking skeleton and activities are terms used to help explain how the story map is organized.
One concern of product owners putting together a story map is that they feel it is so permanent. Story maps are done with stickies or with movable notes (if you are doing it digitally) so that the team members can have conversations about what the descriptions all mean. For example, if you are building a translation application and the story asks for “As a French translator, I would like my French translation team members to be able to review and give feedback on each English sentence I translate, so that I can write the most accurate translation and also one that is best understood culturally for our French customers”. As you read this you can think of several ways a team of translators might do this, however, how does this specific translation team actually work together today without the new app? How will their process need to change once they start using the application? And so the conversation begins with many more questions discussed. The story documents the decisions so that the technical teams can code this feature correctly.
User Story
There are two types of stories an Epic and a User Story.
Definition of Epic Stories
A story that represents a major feature. On the story map this is usually the top row (orange stickies) that groups all the related user stories.
Definition of User Story
User stories are use cases written for the developers so they
Know what to build and with acceptance criteria for the testers so they know that the feature is built as the team desires.
Where user stories come from on a story map. Also the flow of the sequence of the steps and the flow of the priority features.
User stories are generally formatted in the form of a sentence with a benefit at the end. Having a user or role helps the team understand who is going to be benefiting from the feature. The user or role can be an end user, a marketing persona, a team, or even a role within the team. Adding a benefit is important because without one, there might not be a reason to build the feature.
The acceptance criteria is critical to include because it gives the developer the scenarios that define the tests that the team will do to decide if that feature is complete. This criteria is written ahead of time, before testing, and includes functional and non-functiontional information. You can have one or many scenarios. Each scenario is a case where the developer must build the product to handle that situation.
For example, if you have a story for a translation tool that explains that two roles, a translator and the translation team manager both need to approve the translation before the status can be set to “approved”, you would have three scenarios written. Once scenario for when only the translator approved the translation, one where only the team manager approved the translation and the third where both of them approved the translation. In this case you would describe the outcome that would happen in each case. Probably in the first two cases the translation would not be approved and maybe set to a “pending approval” status. In the last case when both people approve the translation, then the outcome would explain what the team might do as their next step.
Why do you need Acceptance Criteria?
Without acceptance criteria the team does not know what exactly they are working towards. Ask anyone that has built a software product about the time they had an Aha! moment when they realized that their software or hardware developer did not understand what they wanted in the end. What happened next to that team? They now had delays in their timeline and even cost increase to their project. Acceptance criteria is a insurance policy against cost increases and project delays. It’s not going to eliminate these two issues completely, but it is going to get you to think about all the possible cases that could happen so that the developers can build you a robust product.
User story format
Story
As a <user or role> I want to <some functionality or feature> so that <benefit of feature>.
Acceptance Criteria
Scenario 1: Title
Given <context>
And <some more context>...
When <event>
Then <outcome>
And <another outcome>...
Scenario 2: Title...
Even though this format is what everyone uses when starting out writing User Stories the goal is to allow the product owner to tell a story, in English and not in programming language, of what they want their product to do. Kent Beck described it this way:
“Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two.”
So in the end, both the Story Map and the User Stories are for the team to continue to have a conversation about what they are building and documenting it. This format also allows teams to figure out what parts of the product they will build first and continue to write stories. A typical cadence is to create the Story Map, figure out what parts of the Map will be the MVP and then write the stories for that first release. Meanwhile the team continues to write stories as they build and release parts of the product.
Fun Fact
The earliest known author is considered to be a priestess in ancient Mesopotamia. Her name was Enheduanna, and she lived in the 23rd century, approximately in the years 2285 - 2250 BCE. She wrote a number of works in Sumerian literature, some of which she narrated in first person. They were religious writings such as hymns and traditional stories.
If you would like to continue to get tips and insights from us then subscribe to our monthly newsletter.
Lenka Davis is a Managing Partner at Fly to Soar. She has worked in marketing, managing projects and building tools in the high-tech industry for Fortune 100 companies and also ran her own business. Follow Lenka and the Fly to Soar Team on Instagram @flytosoarcompany
References
Who coined the original user story template
