Consumer Friendly User Stories
Part of being a Product owner means gathering and translating the data into information based on who is the data consumer. No biggie, we always do that when preparing for client interactions and training content. But can we take it a step further and practice the same skill in our day-to-day business while also writing user stories?
I often see the functional requirement section of a user story written as a paragraph. Some good ones make use of lists and text formatting. All in all, it conveys all the data needed to get the ball rolling. We write stories from the user’s perspective, which is essential to emphasize how the user will be interacting, but that means the developer must first translate the story from the user’s perspective to action items. By the way, don’t we provide the VD(visual design) and UX(user experience) to understand the user interaction? Wait, wait, wait, if we have VD, then what are we writing in the requirement?
I think this is one of the places where we can attempt to make life easier for developers who will consume the requirement to make it into a functional marvel. SO apart from the general formatting of text and using ordered and unordered lists to give structure to the requirement, we can jump to the genius of a table.
So let me explain the genius of a table with an example of user story for an AEM CMS driven website.
Quick context setting: An AEM CMS website has two frontends;
Authoring portal frontend which enables author to add data and configuration used to render webpages
Website Frontend that a web user sees and interacts with.
User Story: As a <website visitor>, I want to be able to <sign in> so that <I can get the member experience>
The mission for the devs: Build the following user story for an AEM content management system(CMS) driven website.
Consumer of the requirement section of our user story will be
- Front end developers
- AEM developers (back-end)
- Quality assurance team members
- Product folks (Business Analyst, Product Owner, Product manager)
The table below breaks the VD into requirements with attention to enabling action items creation easy.
Benefits of using the table structure in this case
- Clear call out that can act as a checklist for the action takers
- Helps the leads to assign task ownership
- It prevents Product folks from writing lengthy, repetitive texts
- Intuitive understanding of the building blocks of the system for the readers
I know you will say, hey, we can’t write everything in tables. Well, you are right, and you get to make that decision, but my only ask is, while we are writing, should we not try to make life easier for people who will take action on the story? The bonus will also be less time spent on communication and fewer bugs and rework if we get it right.
Do you think it’s worth being mindful of the consumers while writing user stories?
