When it comes to user stories, I’ve seen such a range of misconceptions out there that sometimes I’m left just scratching my head.
How is that supposed to be better than old-school specs? I wonder. How is that saving you time or money?
With that in mind, I felt it was time to debunk some of these common myths. Hopefully, one or more of these will either help you get your user stories back on track or make your stories more effective for your development teams.
1. User Stories are not detailed narratives.
They are lightweight specifications describing how features need to work from a real user’s perspective. They are structured for efficiency and to highlight what’s important, not for reading like a story.
2. User Stories don’t need to tell the development team how the feature works.
All the developers need is to understand what that feature is supposed to do – and any requirements and interdependencies, of course. Let your experts on the development team figure out the best way to build it.
3. User stories don’t need to come from users.
Most users don’t really know what they want until they see it. And they don’t know how to write effective specifications, either. Your business and development teams will collaborate to write each user story. The user’s only real involvement would be to provide input and feedback.
4. User stories aren’t the final word in development.
An early user story can always be modified by a later one — especially when new information or feedback is acquired. That’s a huge advantage of Scrum development – it is iterative and incremental. You can make adjustments as quickly as in your next two-week sprint.
5. User stories aren’t one size fits all.
User stories can range from simple tasks to large, complicated modules of functionality. Larger stories, called epics, need to be broken down into smaller pieces before the development team can fit them into sprints. Even smaller stories need to be split sometimes – a rule of thumb we follow at Ascendle is that no single story can consume more than 25% of each two-week sprint’s capacity.
6. User stories don’t need to be independent.
Because each user story is supposed to “stand-alone,” there’s a misconception as to what that actually means. It does not mean that you can simply insert any user story into your production queue at any time. Many user stories, in fact, will have prerequisite stories that need to be completed first (which should also be clearly identified as part of the story). A standalone user story simply means that it delivers a complete feature – even if that feature is part of a larger set of functionality.
7. User stories don’t need to include obvious details.
Including obvious details is a waste of time in writing them, as well as a waste of time in reading them. Remember that Scrum development is a team-based approach, so you’re not worrying about quirks of communication that might derail a single engineer. Instead, focus on those non-obvious behaviors and conditions that the majority of your development team might not know.
8. Everything in your product backlog doesn’t have to be a user story.
Sometimes you’ll run into a task that doesn’t translate well into the user story format. If trying to fit such a task into a user story would cause confusion – or overcomplicate it – leave it out. You can still add it to your production sprint, even if it’s not in user story form. Note that it should still follow your process rules, such as not exceeding 25% of the sprint’s capacity.
9. User stories are not always from an end-user.
The term “user story” is somewhat of a misnomer since it implies an end-user perspective. For development purposes, a “user” is simply a role or persona who uses the production software. This could be IT staff monitoring log entries, business leaders compiling reports, another system, or consumers using the application. The main point of calling it a user story is to track back to whoever’s using that feature so you get a complete sense of what the feature should do.
10. User stories are not a mandated part of Scrum.
In fact, the term doesn’t even appear in the Scrum Guide. But the philosophy behind user stories is so perfectly aligned with Scrum that most Scrum development teams (and Agile developers in general) make use of them.
11. You don’t have to follow a specific user story format.
While there are some commonly used formats, there is no “official” format since it’s not officially a part of Scrum. Your business can (and should) adopt a format that will work for your development teams across many projects. At Ascendle, for instance, our user story format is designed to capture the following:
- Who wants the feature
- What is the feature they want
- Why do they want it
12. There are no real rules for writing user stories.
Writing user stories is half art and half science, in our opinion. As such, there are no real rules or regulations to follow other than your own procedures. Our article, Writing User Stories – It’s Not as Difficult as You Think, will help you set up and create your own. There’s also INVEST, an acronym created by Bill Wake and recommended by Mike Cohn – but keep in mind every one of these rules is flexible and meant to be broken:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
13. User stories are not shared with customers.
Some people think that because they’re user stories, they’re supposed to be shared with – and even signed off by – customers. That is simply not the case. A user story is meant to communicate and prioritize requirements for your development team. Anything beyond that is up to you. Your user stories can be 100% internal documents, or you can choose to share them with customers – as Ascendle does.
So there are 13 user story myths debunked. Share this with your team – chances are that some (or all) of these will come as a surprise. For more information on creating user stories, read our blog post here.
