Writing a good user story seems like a challenge? First things first. Start thinking like a user. A user doesn’t know what kind of technology is being used, has no clue about the system infrastructure or the tool. What is known to the user is the story itself.
Let us jump straight to an example that a user might have: “I need to know the number of users that log into the system every week”.
As a user, I don’t really care whether I get this number in an Excel report or a PDF report. The only thing I need is the number of users. To make the example a bit more detailed, I might say that I need this number so I understand how many licenses we are consuming. By adding the objective to the user story, I am helping the person or the team delivering this report to be more accurate. Another important detail to add is who is this report meant for (user’s role).
So now our user story has changed
“I need to know the number of users that log into the system every week”.
“As an account manager, I need to know the number of users that logs into the system every week so we can manage the licenses we’re consuming”.
As you can see we have added 4 important details:
- The role – the account manager
- The functionality/the feature/the action – to know the number of users
- The frequency – weekly
- The objective – consumption knowledge
A good practice is to answer these 4 questions when writing a user story. But should you ask more? Do you think we can add “how”? Actually, adding “how” will be one of the most common mistakes we do when writing a user story. Check out our upcoming blog to learn which other mistakes you should avoid.