The Story Behind User Stories
Here at High Seas we follow pretty closely to the standards of Scrum, and one of the big mental hurdles of this process is the concept of User Stories.
The question often comes up in training new team members, with new clients, or even when veteran team members get lazy. “Ok I get the whole backlog thing, but can’t we just use a list of requirements or tasks? These User Stories are long and don’t they just mean ‘build this thing’?”
Below you’ll find an impassioned listicle arguing for why User Stories are the best way to break thing into pieces since sliced bread. But first! What is a User Story, again?
User Stories are a standardized format of writing down project criteria that accounts for the type of user, the user’s goal, and the reason for the goal. Who wants it, what do they want, and what are their motivations?
The format looks like this:
As a [type of user] , I want to [goal] so that [reason].
Or, for example:
As a Product Manager, I want to teach you about user stories, so that you’re all sold that this is the best way to break up project work.
Now this doesn’t mean there aren’t individual tasks or more specific requirements. The client and Product Owner will specify any details in the description of the User Story and Acceptance Criteria (which will be the subject of a future blog post.) For instance in my example user story above I might add to the description: “Must be a blog post. Don’t need to include images or graphics.”
And once the team has assessed the user story they will add sub-tasks that account for the work that needs to be done. But the key is that these are sub-tasks to the end goal. Everything that is done is focused on achieving what that user wants.
Isn’t that a great way to think about it?
As promised — my persuasive listicle: Why are User Stories fantastic?
1. Align the Team
They focus the entire team on working together toward an end achievable goal — can the user do what they want and does it satisfy their reason? Rather than everyone having discreet tasks and working in a silo, User Stories force the team to connect on getting things done.
2. Creativity and Collaboration
Because tasks aren’t specified in advance, the team and client get to work together to collaborate toward how that goal is achieved. It fosters creativity (and a much better product) when the exact specifications are not spelled out in itemized tasks in advance. Designers and developers and testers must all work together to conceive and execute on the best approach. Sometimes the solution is simple — a “search” button returns a list of results — but so often we see mind-blowing innovation and highly intuitive experiences because these user stories encourage the team to work together creatively.
3. Motivation to Think
What is the point of completing tasks if you don’t even know who the user is or why they’re doing things? Where is the motivation? (Well, aside from…you know…being paid). Including the reason in the user story itself focuses the team on creating successful outcomes, not just on banging out work. We expect all of our Scrum team members to be passionate about our clients and the work we do. A dry technical task list doesn’t exactly spark engagement in client-focused solutions. When you’re building something for a user, you feel much more personally attached to getting it done well.
4. Considers the Why
It’s important to know the “why” so that we can find the right way to deliver the “how”. It was often the case in the past that once we started executing on some basic specs or requirements for web tools and apps the client or Product Owner would see the resulting work and realize it met the criteria but wasn’t quite right for their users. Or the case would be that the back-end logic couldn’t quite fit with the UX study when they were both done in a silo. When everyone on the team knows and internalizes why that specific user wants to use that piece of functionality we can plan and build on a specific experience from end-to-end.
5. The Client Gets What They Need
Controversial statement: The client doesn’t know what they want. Ok, hear me out, we’re not disrespecting or disregarding client’s needs or subject matter expertise. But we are consultants over contractors. And our expertise lies in delivering solutions. User stories take the misunderstanding and misdirection out of “well, that’s what the client asked for.” by putting it in terms of a challenge that needs a solution.
6. Produce Useable Features as deliverables
Ok, so this is kind of the whole point of scrum (shippable product increments) but it’s always good to remember. If everyone is working toward a user’s end goal at the same time, they’re going to deliver that end goal faster and with more focus. Therefore, it’s likely and even expected that the actual users can actually use the deliverable. Meaning, we can deliver in increments measured by functionality the users can use.
