User stories will improve the way you develop software. Here’s how you can turn this little strategy into big-time success.
Although user stories can come in many shapes and sizes, they are also the foundation of strong agile development. Whether short-and-sweet or super thorough, user stories lay the groundwork for successful software development.
Unpacking User Stories
The purpose of a good user story is fully flesh-out the scope of a project before coding starts. User stories segment a build into manageable tasks allowing you to work in iterations, deliver progress, and maintain direction.
Despite it’s simplicity, writing software without user stories can quickly become like running in quicksand.
When used effectively, user stories give developers a solid idea of what they’re expected to produce and when. They understand the feature, they know who will be using it, what the user wants to do with it, and how they want it to do that thing. The best part, though, is that they know these things before they start coding. This means no guessing and (hopefully) no misunderstandings.
Instead, user stories make it possible to build each software element RIGHT THE FIRST TIME. I repeat, you can fulfill stakeholder expectations in the first delivery. That’s a really big deal for stakeholders, and huge victory for your team.
Ultimately, if it requires persistent rebuilds to get a software product right, you’re doing it wrong.
Strong User Stories Save Time
And time is precious. If you don’t like wasting time, energy, or resources redoing things, user stories can help you gain control over your whole development process.
If you like the sound of that, please read-on to find out how to create user stories and how to use them to maximize your Agile product development process.
What Does a User Story Look Like?
A user story explains a few things about upcoming work:
- what the feature is
- what it does
- who wants it
- and why
Typically, user stories exist in a product backlog.
A product backlog is a prioritized list of items. Just like all criteria of a user story must be met before that item is considered complete (more on this later), all items in the product backlog must be completed to satisfy that product’s definition of done.
User stories often follow a very simple format; like this:
As a [type of user], I want [a feature], so that [purpose/goal of desired feature].
As a user, I want access to a customizable user profile, so that I can add, save, and edit the personal details associated my account.
– or –
As an admin, I want to ability to impersonate users of my app, so that I can see exactly what they see while logged in.
Something called “acceptance criteria” then bolsters those user stories with additional information. Acceptance criteria are conditions that stipulate “doneness.”
Unpacking Acceptance Criteria
Depending upon the complexity of a feature or upon the specifications of product stakeholders, acceptance criteria can be “loose.” Loose criteria simply provide the “meat-and-potatoes” of the user story. Or, acceptance criteria can include the gravy and garnishments, too.
For example, an acceptance criteria for a user profile could be as superficial as, “profile image should be displayed as a circle.” Or as in-depth as, “user profile most contain an option to edit image, add bio, and to change or reset username and password without leaving the page.”
To strengthen a user story, you can include things like these:
- a thorough breakdown of usage requirements
- design requirements and color schemes
- high-fidelity prototypes
- workflow diagrams
You see, the more relevant information you pack into a user story, the more perfect the feature will be.
Acceptance criteria give the developer (the one who is actually building the feature) a vision of it’s appearance and functionality. That’s a critical tool to have, especially if you are building software from scratch.
So, the more specific the user story and the more robust the acceptance criteria, the more powerful a feature can be. That makes everyone happy, right? Your team will be like…
How Should I Write a User Story?
Generating relevant dialogue within a development team is the greatest function of a user story. For this reason, many dev shops use long-hand methods to create them together. Physically writing stories on sticky notes or index cards enables you to arrange, rearrange, breakdown, and map each feature into bite-sized development tasks.
Seeing a physical representation of the user story helps developers visualize the best path to completion.
Seeing and touching something like a story wall– something that maps a development process and can be physically rearranged– helps coders anticipate complexities before they’re stopped by them.
Whether everyone on your team contributes to the “writing” part of user stories, everyone should should be involved when setting acceptance criteria. If a component of functionality is important to the stakeholder, to the end-user, or to the overall performance of the feature, it should be described and established as a necessary acceptance criteria.
Although user stories can always be built the good-old-fashioned way (described above), other dev shops opt for a digital version. You can use software like GitHub to help you create development boards online with user stories that can be edited and dragged-and-dropped into columns organized by development stage.
Here at DevSquad, we use both strategies. We map work onto a whiteboard wall using sticky notes and sketches to carefully plan development tasks. Then, we translate each piece of development into a manageable yet fully thorough user story in GitHub.
In either case, always presented user stories visually. Whether you like it long-hand or digital, make your development process visual.
Epics User Stories…
Sometimes features can get really big. In this case, a short-and-sweet user story can’t always do the trick, and Agile developers will turn to a beefier format called an epic user story.
Remember the Aeneid? The Iliad? The Odyssey? Those are epic, right? They’re stories of war and heroism, of unknowably long journeys that could change one’s life forever.
Remember how software development can feel a lot like that, too? Like a journey of unknowns and new languages that can consume a man inside and out?
That’s when epic user stories come into play.
An epic user story is one that is too large to complete in one iteration of work. It is then broken down into more manageable sub-tasks which are completely gradually (like chapters).
The best way to determine if you’re working with an epic, is to size your user stories. An Agile sizing technique that assigns story points to each user story can help you understand the relative size of each of the stories in your backlog. Sizing user stories allows you to better estimate the amount of development time required to complete it. That’s a separate ball of wax, but here’s a brief explanation of sizing user stories with story points…
Assigning Story Points
It all starts with Planning Poker.
In a nutshell, planning poker utilizes a customized deck of playing cards containing four color-coded sets. Each set is made-up of a series of cards printed with a sequence of numbers. Each number represents a value used to describe the estimated size of a piece of work.
Every developer involved with the build is given one set of sizing cards and, by assigning one card to a user story, he secretly scores his estimation of its size by placing the chosen card face down.
The cards are flipped only after each developer has scored the story (again, by placing a numbered card face down). If all of the scores are the same, your players can move forward to the next user story. If not, each player must defend their score and replay until a unanimous score can be reached.
This exercise does a number of important things for your team including:
- unifying the team’s concept of each segment of work (regardless of individual skill level
- establishing a working velocity (that can be measured and predicted)
– and –
- enabling you to better meet milestones (because you know from the get-go what will be required to get there)
Plus, planning poker can be fun for your team. And fun makes people happy. And happy developers do better work.
All-in-all, planning poker is a super effective agile tool. If you want more information about playing planning poker, click this link: how to play planning poker
Back to user stories!
Which Team Member Writes User Stories?
Writing complete and well-groomed user stories is the responsibility of the product owner. But she is not the only team member who can create user stories. In fact, any team member can add user stories to a working backlog. If certain elements are especially technical, it’s often helpful for coders to assist in the creation of those stories.
For software development to be max-effective, it’s critical that all team members understand the requirements of any given user story. Often, working together is the best way to achieve that.
Remember, the most important part of creating great user stories is the dialogue between all involved team members. This ensures carefully considered acceptance criteria and a unified understanding of the work ahead. Better communication results in better features and better software.
In the end, spending a little more time at the outset of development on carefully planning that development process will result in higher quality work and faster deliveries. That’s a result your whole team will agree on.
If you need some help getting your process off the ground, our free email course can help. Download it now because it’s free AND it helps. So, you can’t lose!
In the comments below, please share your own story about how user stories improved your development process.