If you want to incorporate Scrum or an Agile development approach, or if you simply want a path for creating better apps with better features, user stories are exactly where you need to start.
Although user stories can be short-and-sweet, they are also the foundation of strong agile development. Taking a build and breaking it down into manageable development tasks, the purpose of a good user story is to fully flesh-out work before you start writing code.
This means, developers have a solid idea of the feature, who will be using it, what they want to do with it, and how they want it to do that thing before they start building the feature. This ensures each element is built to precisely fulfill stakeholder visions and expectations the first time it’s delivered (rather than requiring subsequent rebuilds to get it right).
In other words, 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?
Typically, user stories exist in a product backlog. This is a prioritized list of items that need to be developed in order to deliver that product. Typically, user stories follow a 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.
And then those user stories are bolstered by acceptance criteria, which are conditions that stipulate “doneness.” Depending upon the element or upon the specifications of involved stakeholders, acceptance criteria can be “loose” simply providing meat to the user story—or, they can be detailed enough to include thorough requirements, high-fidelity prototypes, workflow diagrams and etc.
For example, an acceptance criteria for a user profile could be as superficial as, “profile image should be displayed as a circle.” Or as crucial as, “user profile most contain an option to change or reset username and password.”
Usually, the more information contained, the more specifically an item can be built. Acceptance criteria communicate the vision of a functionality to the developer who is actually building it (which is crucial). 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?
Because the greatest purpose of the user story is to generate real dialogue about how a feature should be used, many dev shops use long-hand methods to create them. 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; it helps them anticipate feature complexities, and it affords an opportunity to foresee roadblocks that may be lurking in future work.
This is also the ideal time to establish acceptance criteria. If a component of functionality is important to the stakeholder, to the end-user, or to the overall performance of the feature, those elements should be determined, described, and set as necessary pieces in order for a feature to be considered complete.
Here’s another way…
Although user stories can always be built the good-old-fashioned way with pen and paper, 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 on 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.
Sometimes, though, 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 and is therefore broken down into sub-tasks that can be completed 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. This then, allows you to better estimate the amount of development time required to complete each task.
In brief, here is how you assign a story point…
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.
Each 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.
After each developer offers their own score (face down), the cards are flipped. 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 each developer’s concept of a piece of work.
- Assigning a relative value to a user story that can be comprehended by each team member regardless of his skill level.
- Establishing a working velocity so that future work can be measured more accurately.
– and –
- Enabling you to more effectively manage milestones and stakeholder expectations.
Plus, it can be fun for your team. And fun makes people happy. And happy developers do better work.
All-in-all, planning poker is a very effective agile tool. Please go here if you’d like to see more information about how to play planning poker.
Back to user stories!
Which Team Member Writes User Stories?
While it is the role of the product owner to ensure user stories are written, complete, and groomed as necessary, she is not the only team member who can create them. In fact, any team member can add user stories to a working backlog and, if certain elements are especially technical, it’s often helpful for developers to create or assist in the creation of those stories.
It’s critical that all team members understand the requirements of a 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 you’ll have a unified understanding, carefully considered acceptance criteria, and better features that get built into better applications.
Spending more time planning at the outset of development will result in higher quality work and, overall, faster deliveries. That’s a result your whole team will agree on.
Please share your own user story in the comments below!