User Story
In agile framework such as Scrum and Kanban, a user story is the smallest piece of software requirement, stemming from the epic, and written from a user’s perspective. User stories are usually written in the following format:
As a <user>
I want to <do this>
So that <I can achieve this>
Why write from a user’s perspective? It puts developers in the user’s shoes so that they understand not only what needs to be done but why it needs to be done. Why is this important? Let’s look at an example.
User Story (Version A): Allow a branch manager to see the staff’s vacation schedule.
User Story (Version B): As a branch manager, I want to be able to access my staff’s vacation schedule so that I can ensure I have adequate staffing to run the operation.
With version A, the development team will build the functionality in sort of a mechanical manner as they don’t have any reason to think beyond what’s presented to them. But version B will make them think like the branch manager who must ensure there’s enough staff on duty to meet the daily workload. This context helps the development team empathize with the branch manager, leading them to build a solution that lets the branch manager easily spot time periods with low staffing.
Acceptance Criteria
Each user story accompanies a list of requirements called the acceptance criteria that must be satisfied before the user story is considered complete. Acceptance criteria are often written in the BDD (behavior-driven development) format as follows:
Given <user>
When <action>
Then <result>
In the branch manager user story, one of the acceptance criteria could be:
“Given the branch manager wants to see the overlapping vacation schedules of their staff members when he/she clicks on the “Show Overlaps” button, then the information should be displayed in a tabular format containing the Member Name and Overlapping Dates columns.”
Acceptance criteria should be exhaustive, taking into consideration all the ways the user may interact with the application. It should also contain tests for situations arising from technical and network connectivity issues. Writing comprehensive acceptance criteria are crucial because they form the basis for quality assurance (QA) testing and help developers assess the effort with better precision.
Definition of Done (DoD)
While acceptance criteria are written for individual user stories, the Definition of Done (DoD) is a common set of requirements that all user stories must meet before they are considered fully done. Continuing with the branch manager user story, some of the items included in the DoD could be: acceptance criteria met, unit tests passed, code peer reviewed, design met the Web Content Accessibility Guidelines (WCAG) Version 2.1, etc.
The definition is important because it acts as a gatekeeper to catch undesired variations in the way features are built and functioned. It brings consistency and keeps the development team focused in producing a cohesive solution. Lastly, it serves as the agreement developers have made with the stakeholders about delivering features that meet their shared and agreed-upon definition of done.