I’ve held many roles within the agile software development lifecycle, from developer to architect to scrum master. The one mistake I’ve seen developers commit over and over again is not including a sufficient level of detail in their user stories.
Here’s a real life example of a user story I saw at a recent sprint review, “As a user, I want edits to be reflected in the data, so that I don’t need to refresh.”
I get it. Developers want to develop and they don’t necessarily want to write about it. But, looking at this example, a number of questions arise. What edits? Which data? Refresh what? Unfortunately, that was the extent of information available for this user story—other than the point value assigned and the fact that it was considered done. Good luck to anyone trying to validate that.
Why this is problematic
This is problematic for many reasons. During the sprint, your team will be flying blind as no one will be able to remember the nuance discussed during sprint planning and no one will know what is going on with the story other than the creator or the developer who is working on it at the time.
Given this lack of team visibility, there is a real chance that changes made may impact other components and team members. Developers and testers should be able to pull up the scum board and quickly understand what other work is in progress and how it might impact their work. When your user stories are ambiguous there is a real opportunity to introduce bugs, cause friction in the team, or force future rework.
When it comes time to demonstrate the functionality at the sprint review, you are also leaving your product owner in the dark. They will be lost as to what is supposed to be happening and won’t be able to understand the feature’s value. Your scrum master, and in some cases the actual developer, may struggle to remember the functionality being presented to the stakeholders at the time. This is not a good look and can create an embarrassing situation for the team and pummel your collective credibility.
Lack of details in your stories also limits any historical traceability or understanding of how the product evolved. There will be no context as to the purpose of the functionality or how it was resolved when revisiting these user stories in the future .
At the end of the day empty user stories represent poor systems engineering practices, reflect poorly on your professionalism, and provide no lasting value to the product or team.
How you can fix it
With all of that said, what you can do to fix the problem is quite easy. You simply need to write more. Provide sufficient details where anyone would be able to pick up the story and understand what is going on.
Think of the problem or feature you are addressing, especially through the lens of an end user. Consider what you would be doing when interfacing with the system at that particular point in the workflow? What would your expectations be as a user when you take a particular action? Be descriptive and think about the who, what, when, where, and why of the functionality. Reference specific UI elements or data sources that are being modified and try to explicitly walk the reader through what is going on.
You don’t need to add robust technical details as the user story is intended to mainly address the business need. The technical details will be worked out by the developer when meeting that need during the sprint. Which brings up another element needed for solid user stories, a resolution.
When you finish the story, add some information as to how you implemented the feature. Again, I’m not saying you need to write a novel but someone should be able to quickly understand what was requested and how it was accomplished.
Also keep in mind that user stories are living documents that may be updated throughout the life of the sprint. Add details or clarifications to the description as you move through the sprint. It’s better to have more details than to be left with emptiness at the end. Just make sure you don’t change the spirit of the user story as that represents the agreed upon functionality requested by the product owner.
In conclusion, it’s necessary to demonstrate your acuity through a lasting trail of documentation in order to be considered a professional developer and one who is respected for their work product, . Only then will your team take you seriously and opportunities may be presented for growth. It’s such a small change but one which could position you for real advancement.