The value of “good” user stories
Pigs & Chickens, Scrum Master, Sprints, etc., we have been hearing these terms for quite some time now. They are related to the (not so) new software development methodology called Agile based on the Agile Manifesto generated by (what was later called) the Agile Alliance.
One of the guidelines for agile software development, is the use of User Stories to depict the needs of the user from a functional perspective; and while I won’t go into details of what agile is and is not, I do want to talk about user stories and the value of them for a development team in a churn.
User stories are short concise sentences that express what used to be called “system requirements” in a different format. The common template for user stories goes like this:
As a <Role>, I want <some goal/desire> so that <some reason/benefit>.
- A simple title (description)
- Discussions on the smaller details
- Ways to ensure that the work is done (acceptance criteria).
At some point in time, your massive list of items will be reduced to a column/row format document. In the context of user stories, most likely the field to be included is the title or short description. Make use of that concept and ensure your story titles are clear and to the point. Avoid items like “fix XYZ issue” or “admin console.”
Some user stories are too large or hard to summarize, consider these Epics and treat them like the parents of many additional user stories to be flushed out later on.
Sometimes referred to as the long description or conversation, this is the section of user stories that gets puzzling for many teams. Along with your backlog grooming, where stories are added/removed, ordered and re-prioritized, story grooming should also be part of the daily team activities. Each user story should be revisited and modified as the project moves along with details that better explain how the story is to be developed.
The team as a whole has ownership of stories. Therefore all team members are encouraged and asked to participate or contribute with additional information for stories. It is important to remember, that by extension, the customers are part of the team. Try to encourage the customers to participate whenever possible; increasing the level of engagement from the customers, is always a benefit for the team. Not only does it increase transparency, but also helps the team feel like, “we are in this together.”
The last part of a user story is its acceptance criteria or confirmation. These are small user acceptance tests for which the outcome can be measured in a binary format; it either works or it doesn’t. When organized correctly they can be given to a customer to follow and ensure the system’s behavior is aligned with their business needs. In essence, by using these tests the customers can confirm the successful delivery of a feature.
In addition to confirmation, the acceptance criteria is by nature one of the key drivers for the design and interactions of the deliverables. The user experience design process is intrinsically tied to the acceptance criteria and can be summarized in these tests.
Self-contained and valuable
A user story is a self-contained unit of deliverable work. Stories contain small chunks of every step in the development lifecycle, (analysis, user experience design, technical design, development and testing).
A user story encompasses business analysis as part of its description and acceptance criteria. Stories should contain a design element that includes: user interfaces examples (or mockups), infrastructure needs or changes, and software development direction (architecture) for the development team to follow. Lastly, it should guide the testers on what and how to verify the unit of work being delivered.
An important aspect of user stories is that these should provide value to the customers. One preference is to start (or prioritize if possible) stories that are tangible or observable. This does not mean to forget all backend logic or to move it to the end of the backlog, but to provide some of the most impactful interfaces to the customers quickly, so the vision of the project is aligned with the development. In the long run this habit will help integrate small changes earlier and minimize large redesigns later on.
When short on time
Agile methodologies adapt incredibly well when short on time or on time-bound scenarios (ahem… hackathons). A common mistake is to skip many of the elements of a good user story. While this may feel like it saves time, in the long run, it will impair the team’s ability to deliver quality features in an already short amount of time.
Share your experiences
Let me know your experiences with great user stories you have written or some of the not so great ones that you have run into.