3 Common Mistakes To Watch Out For When Writing a User Story

In our previous blog post we went over 4 questions you should ask yourself to write a good user story. This week we will introduce you to the top 3 mistakes a project manager might find in user stories.  Let’s start with an example from the previous post:

User Story Example 1: “As an account manager I need to know the number of people that logs into the system every week so we can manage the license we’re consuming”.

Great – Right? But what if the author is not really giving us a clear picture?

1. The SME may go technical and emphasize the “How”

Here are some of the examples of replies that are clearly, not user stories:

• First, we define the documentation process…
• Our team is busy defining a query that we may use…
• We are still considering this as one of the proposals…
• The dev team is writing a function to…

These kinds of technical assertions or parameters are really out of scope for user stories and should only be answered by the technical team on how to reach the goal and how to deliver the work that arises from the user story.

The technical “how” should be a part of the backlog grooming or requirement gathering stages that take place before the story is divided into smaller tasks.

The “how” can be tricky. In every situation the “how” can influence the objective. If it does so to a significant enough degree (expands effort, cost, duration) an approval from either the sponsor or the product owner will be needed. When defining the “how” during the planning & analysis stages of the Software Development Lifecycle, the “how” (bytes and bits/nuts and bolts) should be reviewed/approved by the designated Solution Architect. The Architect as part of their role should be able to advise upon the requirements and accurately judge whether they reflect the goals stated forth in the user story. Of course, these requirements stem from the original sponsors or the product owners.

2. More is not more. Extra details can jeopardize the objective of the user story

Don’t go into too much detail too early. Only when the user story and the solution design are completed can we start elaborating and putting more details for the delivery team. First start with the goal, then add detail to ensure that the main objective of the user story is met. Adding in too much detail too early has the unintended consequence of possibly adding in risk as requirements can be inadvertently added in the descriptions.

Any discussion of the details before the user story is understood from a functionality and a design perspective will waste the time of the team and the stakeholders.

3. Too High Level

Sometimes no one can understand the user story simply because the story was written from the 10,000-foot high perspective. Example: “I want a report”

Sure… but what do you want in that report? What’s the objective of this report? What does this report do? How frequently do you want to see this report?

This kind of user story should not be accepted and has to be sent back to the user for more elaboration to a point where we can identify the four questions.