Great Software and Web Development Begins with Storytelling.
A critical component of developing exceptional applications is translating the needs, desires and activities of the app’s users into working code, or features. While this is an obvious observation, it isn’t as easy as it may sound. Many projects go off the rails because the project team fails to communicate desired features and requirements effectively. Not everyone involved in a project uses the same language, and technological jargon can often get in the way of true understanding.
So how can project teams ensure they are all understanding things in the same way? How can developers be certain that they are building what the client wants?
The answer, as the title of this blog implies, is to create user stories!
What is a User Story?
A user story is a very high-level description of a requirement or feature, containing just enough information so that the developers can understand what an experience should be like for a user or users. They most often describe a specific task as it relates to one or more users, as well as a brief rationale for that task. User stories are framed from the perspective of the users, and it is best if the genesis of these stories comes directly from the users themselves.
Why Work with User Stories?
They help the development team better assume the role of your users by articulating needs and desires from that perspective. They also create very clear expectations of what success looks like for each user and task pairing. Lastly, user stories help the development team scope the complexity and difficulty of developing a specific solution, relying on their experiences with similar processes and tasks on other projects.
How Are User Stories Created?
A user story begins as a simple statement about the user, a task, and the goal of said task. They are generated through a simple formula:
“As a <type of user>, I want <to perform some task> so that I can <achieve some goal/benefit/value>.”
Examples:
- “As a staff member, I want to be able to post interesting ideas in a feed so that my teammates can give me feedback.”
- “As a customer, I want to be able to chat with support so I don’t have to wait for answers.”
After the initial list of user stories is drafted, the team has a brief discussion about each story. The purpose of this discussion is for the developer(s) to dig deeper into the requirement and try to fully understand what the user will experience when undertaking the task and what successful completion of the requirement looks like (aka. Acceptance Criteria). This generally creates much more specific language that the developer can rely on when building the requirement. The team documents the results of the conversation along with each user story so that the developer can refer back to the conversation during the process.
Example:
In order to complete user story #1 (above), here is what needs to be considered.
[Given] the user is logged into the system, and there is a feed of topics that other users can see and interact with,
[if] the user wants to share an idea with the team,
[then] provide a text editor to write a message or post content, allow the user to submit the content, and provide a similar text editor for other team members to comment.
Why User Stories Work!
The simple answer… because they bring the team together to talk about ideas and requirements. They eliminate assumptions by creating conversations. They force a brief period of active listening, where questions can be asked and statements clarified. They create transparency in what is generally viewed as an opaque process.
MBO16 Presentation
I presented recently at MBO16 on this topic, I’m including that presentation below for your information. If you have additional questions or would like to see a version of this presentation in person, email me: JasonW at Rocketbuild.com
