Agile methodologies are light on documentation. In fact, one of the four agile manifesto items asks us to value working software over comprehensive documentation. This may not make sense to a lot of young product managers who have never seen the hefty pages of documentation that traditional software development lifecycle used. Sadly, this is still the practice in many organizations. Documentation per se is important provided it is created meaningfully as per the requirement in a quantity and has a meaning and a purpose. Documentation that is created as part of a ritual following generalized templates with irrelevant entries, etc. is toxic.
User stories are the kind of documentation that I like and is used in frameworks like scrum. A user story, as the name suggests, is the story of the user using the software a.k.a product. What is the user trying to achieve and why is what forms this terse documentation. It usually follows the format
As a USER, I want to —————–, so that ——————–.
The beauty of user stories is that it puts the user at the center of all development. Note that we are focusing on the WHAT and WHY. This is product management territory. HOW is where the development team comes in and defines how to achieve the what. Product manager or product owner writes these stories based on user research that may include qualitative and quantitative methods. Development team adds tasks that are needed for implementation and testing. This is how we truly make technology as a means towards an end.
The user stories are also organized into what are known as Epics. A group of stories is what forms an epic. This is helpful in organization. Just imagine all Tom and Jerry stories/episodes grouped into one group to distinguish them from The Flintstones! A prioritized product backlog provides direction to the product team in an organization. Development teams pull items from the top of the product backlog into the sprint. A sprint is a time duration of 2 weeks or 4 weeks during which the development team gives life to those stories. Again, this is where it becomes challenging in certain organizations where release management has a fixed process and release happens either at the level of features or stories. Feature is an intermediate hierarchy between story and epic. I am now digressing into the scrum framework. That is not the intention of this article.
Coming back to user stories, let me know concoct an example
As a job seeker, I want to upload my resume to the system and want the system to auto populate the fields required in the job application, so that I can use my time efficiently to fill many applications in a day.
This is where product management also becomes a sort of art and not a science. You can get creative in writing these user stories. How about
As a frustrated job seeker, I want to…….
Adding an adjective brings about the emotions associated with this feature for the user. So, a smart development team now tries to implement this feature to remove the frustration and not to add to it! Have you ever experienced this frustration when you upload your resume and all the fields are messed up for you to clean?
You cannot talk about user stories without talking about acceptance criteria. User story alone is a terse statement and does not provide the details that the development team needs. The user story only provides a high level context which is very important nevertheless. So, how do you add details. One way is to hit two aliens with one stone by writing well defined acceptance criteria. I really do not like hitting the innocent birds!
Acceptance criteria are usually written as a checklist and define what is the expected functionality when the user story is implemented. Let me try to create such acceptance criteria for our user story
- The user interface must follow the visual design as per ADD THE PROTOTYPE LINK
- Standard accessibility criteria as defined in THIS EPIC must be met (Link the accessibility link that has all user stories derived from WCAG guidelines)
- The upload button must be inactive until a valid file is being uploaded from the user’s computer. A file is valid if it is less than or equal to 5MB and is either in PDF or .docx format
- Once the upload starts, upload progress must be displayed in the modal as per the visual design
- Once the upload completes, the upload progress modal must close automatically and the user must be on the first page of the job application with fields filled in automatically
- Only those fields that can be extracted from the resume with a 100% certainty must be filled. Other fields must be left blank for the user to fill in.
- Phone number must be formatted in a standard manner from the digits extracted from the resume.
- So on and so forth
A product manager must check each of these criteria once the development and testing is complete. Unit testing and regression testing are common forms of testing that are used by the development team. Once the user story passes both the technical testing and the product manager is satisfied that it meets the acceptance criteria, the story is said to be done. In some instances, certain parts of the acceptance criteria may not be satisfactorily met and yet a decision may be made that it can be released and improved in a future sprint.
What is important for the product manager here is empathy. One must put oneself in the shoes of the user and write these user stories and acceptance criteria. You must use your insights from user research. Empathy is easier said than done because of the prejudices that we carry with us. With practice, such prejudices and assumptions can be minimized focusing purely on the different persona users in question.
Sudhir Gupta's Blog 