This is a question I got asked a few days ago by one of our engineers. It caught me by surprise as user stories are a common trait in modern and agile software development and are used far beyond Scrum in all kinds of agile methods, even Kanban. My short answer was a simple: YES!

Why are user stories important?

Imagine the following: You are in a brainstorming session with your cross-functional team consisting of engineers, a product manager and a designer. At the end of that session you have discussed numerous ideas and voted for the best idea which you now want to implement as a team. You do an ad-hoc planning and then get to work.

This kind of process will feel a lot like trial and error. Making the problem worse is the (not so small) possibility, that everyone on the team is having a different picture in their head of what should be accomplished.

This is not agile. This is not lean. This is chaos. Very inefficient chaos.

With a good user story these problems are a lot less likely to happen.

Alignment of the team is achieved early on and not left to chance The entire team has a clear understanding of what should be achieved with the story: Everyone knows when they reached the goal of the story. Estimation of complexity and/or cost can (and should) be done before starting development, which in turn allows the team to change scope or postpone the story altogether, if necessary.

A user story doesn’t prevent collaboration. A user story doesn’t prevent refinement during the actual development. Both collaboration and refinement are explicitly triggered by the process of creating a user story and at the same time necessary as a user story should not be a lengthy document like a Spec. A user story is the anchor for the team that forces deliberate thinking, clarity and ownership of the entire team.

Pro Tips

Make sure to use a standard structure for your user stories. You want everyone to be able to quickly read a user story without having to sift through unstructured text. A good framework for user stories incorporating ideas from BDD can be found here.

Before estimating the complexity / cost of a user story the story should be ready for estimation. This doesn’t mean that all auxiliary information like designs, icons, copy etc. have to be present at this time — everything else should be “good enough to start”. As a user story should be a living document, expect details to change over time.

As a general rule: Don’t increase the scope of a user story during development. Decreasing scope while reaching the same or even better result is highly welcomed as it reduces waste. If you feel you need to increase the scope, default to writing a new story, don’t bloat the story in progress.

Mockups/Designs, icons, copy etc. should be attached to the user story before actual development starts. This makes it a lot easier to keep up the flow and reduce blockers and wait time.

Size matters

For user stories size does matter. You should always be able to finish a user story within one iteration — ideally try to split user stories once they cannot be completed within one week. A small user story increases the precision in estimations and at the same time allows more frequent decisions about “What is the most important thing we should do next?”. You have the ability to be more responsive to the market and things you have learned as a team.

If you take user stories seriously, work for your team(s) will feel a lot less like chaos and more meaningful as waste will be reduced. It’s not so much an investment in terms of time, but much more an investment in discipline.