User Story – Start With Training Wheels
What Is A User Story, Anyway?
One of the most significant challenges across all businesses within any industry is ensuring that everyone is on the same page. Regardless of whether you are dealing with software or teaching children in school, there comes a need for an effective and efficient method of communication. A novel idea called a user story surfaced in the 90s and focused on meeting the needs of the end user while at the same time removing the problem of the interpretation of requirements away from all parties involved in delivering the requirement. A user story ensures the desired outcome is focused on the end-user while leaving room for collaboration where people can suggest things to improve or build-upon goals outlined in the user story. The objective is to make sure the expertise of everyone involved is maximized.
A Simplified Form of Training Wheels
Traditionally, user stories were written on a paper note card or index card, Ron Jeffries, one of the authors of the Agile Manifesto, describes the three aspects of a user story, which is card, conversation, and confirmation. Instead of using paragraph form, these snippets provide the objective and direction—the who, the what and the why of the need. The basic format is:
As a <type of user>, I want <goal> so that <reason>.
As you can see, this description is short but clear and specific. It opens the door for multiple talking points with anyone that has a stake in it. Each Epic, a large user story, will have a series of small user stories, potentially for different demographics or types of users. Or, a set of “conditions of satisfaction.” For example, a premium user, a subscription-based user, and a freemium user will have different features, functions, and accessibility for people to build.
Conditions of satisfaction, aka acceptance criteria, would include some of the multifunctionality that is needed to address the need altogether. For example, when placing your online food order, can you request substitutions or extras? Do you have the option to pay online and in person? Can you cancel or change your order after it’s been placed? Or, if human resources software is being developed to manage scheduling, vacation and time-off requests, are employees able to trade shifts without management approval? Can they cancel a time off-request after it’s submitted? After it’s approved? Will paper requests be added to the online system?
A Balanced Approach With A User Story
The card has a primary goal, that branches out into the multiple functions or conditions of satisfaction that can create some diagram, map or workflow. Many teams will utilize a whiteboard or wall as a visual method of talking through the objectives. The benefit is not just to ensure that the people building it understand it, but others get into the mindset of the end user. This is essential to refocus everyone on the end user, not just the business goals.
Not only does there need to be a balance between the end user and the business, but between the business and their development team. Without a doubt, taking an idea from concept to fruition is a challenge—and there will inevitably be some unexpected roadblocks along the way. The agile mindset promotes feedback on product and process sooner, which helps you to course correct sooner. A benefit of user stories is to minimize the gaps in communication and allow for feedback to occur sooner. It will also help make estimates and timeframe realistic and easy to deal with.
Minimize Assumptions And Miscommunication
It is not uncommon for people to make a few assumptions along the way. As a tenured professional, it is easy to forget that everyone does not have the same professional skillset. Even if a someone has completed similar projects in the past, various assumptions must not be made—because a different approach or strategy may be needed. Like the citizens of Babel, everyone speaks different languages with industry terms that may need to be explained along the way.
While the snippets of information contained in the user story are essential to success, the cards are more than words. They are truly placeholders for a conversation. Remember these simple artifacts can be removed or changed as people work through the details and set expectations. Take an iterative approach while building user stories, so that any just time information and end-user feedback is included. These things will virtually eliminate gaps in communication.
In 2016, Ron Jeffries tweeted “as an author of the Agile Manifesto I want that stupid story format to go away so that people can get to the essence of user stories.” The user story format has been used as a crutch by many people and organizations to standardize requirements in a rigid, inflexible way and to replace talking to people. The essence is driven by the conversation, both verbal & non-verbal cues, that occurs between all parties involved working toward a common goal. There is nothing that can replace the essence, so please remember that it is ok to start with training wheels, but free yourselves of those constraints and learn to ride with the wind.