What’s the Most Important Part of a User Story?

What’s the Most Important Part of a User Story?

Looking at the user story template, which part of the user story is the most important part? Is it the Who, What, Why, How, or Acceptance Criteria?

Let’s first look at the How – It’s important to note that the user story does not contain details about the How. Generally, the how are technical tasks that are determined just before implementation typically in Sprint Planning. The user story is written is business language and does not contain technical jargon.

The What is fairly straightforward and defines the feature we are building.

The Acceptance Criteria further clarifies the What so we have a better understanding of the deliverable and when it will be considered complete.

The who helps us determine who wants a particular feature and thus helps in prioritization. When building an application, we might focus on certain market segments before others. For example, when the first iphone came out, the target audience was regular consumers and not business customers. At that time, blackberry was the primary mobile device used by business customers. Features important to business customers, like email integration with an exchange server, were de-prioritized and were not part of the first version of the iphone.

The Why helps us determine business value of a particular feature. This also helps with prioritization as more valuable features will be delivered first. It also helps in providing the reason a certain feature is being requested. By explaining to the team why we want a certain feature, the team might come up with a different way (What/feature) that achieves the same objective and is easier or faster to develop. Without that why context, the team will just work on what was asked of them and we might miss out on better alternatives.

So, which is most important? Some will say they are all equally important, but most point out the Why as the most important because that is where we capture the value statement.

This is a trick question! As the most important part of the user story was not listed as a possible option.

The most important part is the conversation! This is key because it is so frequently overlooked. A user story is not documentation of the requirements but rather a representation of the requirement. It is purposely high level and not detailed to encourage individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

The only way we can minimize documentation is by increasing on-going conversations and collaboration between the customer and the development team. The user story is a place holder for these conversations happening throughout the Sprint as we refine the product backlog. A user story should be discussed and fleshed out over and over again as it moves up in the product backlog getting further and further refined until it is fine grained enough and ready for implementation. Some stories might require additional documentation like a flow chart or a wireframe. Other might just require verbal discussion and confirmation. The key here is that any documentation created is due to an ask by the team that will help them develop the feature and not because our processes say we must produce docs (that no team member needs or asked for).

If you have a disengaged customer or product owner that is not available for these ongoing conversations, you’ve lost the opportunity to clarify, collaborate, easily respond to change and focus on working software. The use of user stories is not a requirement but rather a recommended technique for these benefits, as discussed in this post as well. Writing a User Story once that is a couple of pages long and never revisiting it via ongoing conversations is the same as a traditional requirements gathering technique, just using new “cool” lingo.

To learn more about user stories, check out the entire Art of Storytelling Series:

Reference and recommend resource: User Stories Applied by Mike Cohn

Close Menu