Introduction
Welcome back to The R2D Method, a guided series for how to implement the essential planning and delivery processes of successful software businesses.
This is lesson four.
If you’ve missed any of the previous lessons, you can register here to catch up.
Getting Started with Delivery Processes
In the previous lessons, we explored essential activities for product planning.
Now it’s time to start delivering.
Over the next three lessons, we’ll introduce you to three essential processes every software delivery team needs in order to develop and ship digital products effectively and efficiently.
By effective, we mean shipping products and features that are focused on delivering value to your customers and for your business, rather than adding features for the sake of features at a cost that nobody measures.
By efficient, we mean delivering software in such a way that multiple team members can contribute concurrently without creating problems for each other, that code deployments can be handled by anybody with the press of a button (and rolled back just as easily in the event of an issue), and that work completed in a cycle is typically commensurate with how much work was planned for the cycle.
These essential processes are:
- Epics and User Stories – the art of writing short form product requirements
- Sprint Planning & Backlog Reviews – conducting meaningful and right-sized planning and review sessions
- Code Base Management and Deployments – managing source code, file revisions, and automated code deployments
Let’s get started.
Lesson 4: Epics and User Stories
Who should decide what gets built, engineers or business people?
In fact, the answer is neither.
Our customers, and the people who use our products, should drive the conversation about what to build and what to build next.
The process science of learning what our customers are trying to accomplish with our software, and why those goals are important to them, should be an ongoing exercise, not a one-time fact-finding mission. This is known as continuous discovery, a topic you can learn more about in our training library.
The duty of designers, developers, and department stakeholders (the “delivery team”) is to come together to solve problems for our users.
The “user story” is a specific format for writing short form product requirements that centers the user’s perspective.
When written correctly, user stories are inherently focused on creating value for the user.
What are Epics and User Stories?
User stories are a way of documenting work that needs to be delivered, written from the perspective of the user.
Epics are user stories that describe bigger goals.
Typically a story starts as an epic and gets split apart into smaller, related stories during the delivery process. We’ll explore this more below.
Here’s an example to quickly illustrate the difference between an epic and a user story:
- Epic: I want to buy a house (so that I can raise my family of four comfortably)
- Story: I want to apply for a mortgage (so that I can buy a house)
- Story: I want to pay down my credit card debt (so that I am eligible for a mortgage)
- Story: I want to find a local real estate agent (so that I can start shopping for houses in my area)
Notice how all the stories above express the wants and needs of the user?
Notice also how each story is complete unto itself?
Lastly, notice how all the stories when organized together, seem to relate to the the bigger story (the epic) of wanting to buy a house?
You can have user stories without epics, but you will never have epics without user stories. This is because the function of an epic is to show the connection between user stories that relate to a bigger idea, theme, or feature.
Typically stories start as epics and get split apart, but it’s also possible for an epic to emerge (thematically) from a set of user stories.
Card, Conversation, Confirmation
Whenever you read about user stories, you’ll notice they are often visually depicted on sticky notes. This is because many Agile teams used to write them on actual sticky notes or cue cards. Some teams still prefer physical cards, but most teams today create user stories digitally, in tools like Jira, where they are generally referred to as stories or tickets (and rarely as “cards” anymore).
One reason for the small physical format of cards, was to prevent teams from writing down too many details about how the feature should work, look, and perform without first talking about it. By limiting the physical space available to a few short sentences or bullet points, you force a conversation.
In the image above, a sticky note from one partner to another seeds an intention (steak and wine for dinner), but there are questions that still need to be asked and answered, like, What kind of wine? Red or white? Earthy and full-bodied, or youthful and fruit-forward? How would you like your steak cooked?
The “card” seeds the “conversation.”
The user story captures what our users want to do and why, and the team co-creates the solution; first through a discussion, and later by producing actual designs or code.
The conversation takeaways- the “confirmation”- get recorded so that later there is a measure of whether the solution was implemented as discussed. We’ll expand on this in the section on acceptance criteria.
Formats
By now much has been written (and debated) about user story format. In short, user stories address three questions:
- Who is the user?
- What do they want to accomplish?
- Why do they want to accomplish this?
Written in user story syntax, a card looks like this:
Notice that the language is non-technical? This is because user stories are written from the perspective of the user, not from the perspective of the designer.
A real-life user would not likely say:
“I want a button that has a rounded border of 25px and a hex value of #A31E22.”
A real-life user might say:
“I want a way to save my progress and return to it later.”
The first example describes how a specific button will look, the second example describes the goal, for which a “save button” (with rounded corners and a red background) might very well be the solution.
The user asks, the delivery team creatively delivers.
Acceptance Criteria
So a user story begins the process by saying:
“I want to do this thing for this reason.”
Then, the delivery team, made up of designers, developers, and department stakeholders, come together to discuss:
“How might we solve that for our user?”
One person suggests:
“We could add a button that says ‘save draft’ and it could preserve their progress somewhere so they can return to it when they want.”
Another adds:
“We could make it so that the button only appears after there is some data entered into the fields, in order to reduce clutter and prevent people from saving empty screens?”
Another says:
“Because it’s a primary action, the button should be treated with rounded corners and a red background.”
This is co-creation. This is how features are formed from the kindling of user needs and wants. This is the intersection of feasibility, viability, and satisfaction that successful delivery teams operate at. This is the conversation that informs what is called “acceptance criteria.”
Specifically, acceptance criteria provides clear, written confirmation for how the team has agreed to implement a feature.
Acceptance criteria should:
- Be included inside the description of a ticket (or on the back of a card if you’re doing it old school)
- Provide functional direction for how the feature should work
- Provide non-functional direction, such as how the feature should look
- Provide performance direction, such as which endpoint the API should call
Most critically, acceptance criteria should yield a clear pass or fail when tested against.
This last point is important because it lays the groundwork for another vital process we aren’t covering here, which is quality assurance (QA) testing. Well-written acceptance criteria is testable, and the test shouldn’t require the person who wrote the code or created the design to validate it.
Bugs and System Stories
Not all tickets require user stories or benefit from being written in user story format. Among these are bugs and “system stories.”
A bug is a code-level error that produces an unintended or incorrect result for the user.
A “system story” describes a functional implementation that doesn’t inherently create user or business value, but nonetheless needs to be done and tested against.
An easy syntax for system stories is:
Some example system stories are:
- Generate a user id for all new registrants
- Change the text in the hero banner to say “TDF is a leader in software delivery”
- Merge the data for duplicate transactions
When do we write user stories?
User stories are being written by software delivery teams all the time.
Some teams even dedicate regular meeting time for the purpose of writing stories together, a ritual called “story time” or backlog refinement. We’ll cover this in the next lesson.
Writing user stories is essential to the process of building whole software systems or complete features, as well as prescribing improvements to existing systems and features.
When building a brand new system, you may write a bunch of user stories upfront and then write more after you get some initial feedback about the product from testers, and then ongoing as the product evolves.
If you have a software product in market already, you may be regularly translating user suggestions for how to make the product more helpful or easier to use, into user stories.
Even if you’re new to software development, you already have the knowledge you need to start practicing the art of writing short form requirements.
Where do we put user stories?
Your user stories will “live” in your product backlog. In tools like Jira, the backlog is quite literally a section of the software you can navigate to.
If you’ve recently completed a story mapping workshop (see lesson three), you may already have partial or even complete user stories. If you story map using an online tool like Miro or Stories on Board, you can export these directly into your product backlog.
Now begins the process of building the product.
—
Keep an eye on your inbox next week for Lesson 5: Sprint Planning and Backlog Reviews
Not yet registered for this course? Sign up here
Would you like us to guide your team through a story writing workshop? Book here