Loading...User Stories enable teams to deliver the right products fast. Learn all about what they are & use these tips to write more purposeful User Stories.
How do you decide what a software system is supposed to do? And how do you communicate that decision to colleagues and customers?
This can be tricky because each participant has different needs.
Project Managers need to track progress. Programmers need to implement the system. Product Managers want flexibility. Testers want to measure. Users want a functioning system. You get the point. Every team member has their own agenda.
What Are User Stories?
User Stories are an integral part of an agile approach that shifts the focus from writing about requirements to talking about them.They are straightforward, concise descriptions of the desired end goal told from the perspective of the user, usually (but not always) the Product Owner and typically follow a simple template:
As a user, I want action so that business reason
.
After that, “Acceptance Criteria” or defined boundaries of the User Story are outlined and used to confirm when a story is completed.
Source: https://medium.com/
User Stories are composed of 3 elements:
- A written description of the story used for planning and as a reference point
- Conversations about the story that serve to flesh out the details
- Tests that document these details & determine when a story is complete.
Refer to these as the 3C’s: Card, Conversation, and Confirmation. This formula (from Ron Jeffries) captures the components of a User Story:
- Card (or often a Post-It), a tangible token giving physical form to what would otherwise be abstract.
- Conversations taking place at different times and places throughout a project between the various people concerned with a given feature of a product be it customers, users, developers, testers. This conversation is largely verbal but often supplemented by documentation.
- And finally, confirmation (the more formal the better), that the defined objects have been reached.
Why Do We Need User Stories?
User Stories emphasize concise verbal communication while focusing on the human element. This kind of conversation encourages the entire team to collectively participate in finding the best solution from the user perspective, and facilitates transparency throughout the collaboration.
User Stories use a common language that can be understood by business and development people alike.
They can be readily used in project planning. User Stories are written with a timeline in mind so each participant can estimate how labor intensive and complex their part will be. Also, a story is implemented all in a single iteration of an agile project.
How to Write a User Story?
User Stories are written throughout an agile project. Usually, a story-writing workshop is held near the start of the project. Everyone on the team participates with the goal of creating a product backlog that thoroughly describes the functionality to be added over the course of the project or a 3-6 month release cycle within it.
Some of these agile User Stories will undoubtedly become parts of an “epic” or larger body of work. These epics are later decomposed into smaller stories that fit into a single iteration. Additionally, new stories can be written and added to the product backlog at any time.
Each User Story once implemented is expected to yield a contribution to the overall value of product, regardless of the order of implementation. These and other assumptions about the nature of User Stories are captured by the INVEST formula.
The INVEST mnemonic is a breakdown of the characteristics of a quality User Story.
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self-contained, in a way there is no inherent dependency on another user story. |
| N | Negotiable | User stories are not explicit contracts and should leave space for discussion. |
| V | Valuable | An user story must deliver value to the stakeholders. |
| E | Estimable | You must always be able to estimate the size on an user story. |
| S | Small | User stories should not be so big as to become impossible to plan / task / prioritize with a certain level of accuracy. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible. |
Source: https://mozaicworks.com/blog/splitting-user-stories/
User Stories must be written with the user at the top of mind. They should remain your focal point. If you don’t know who the user and customer are or why they would want to use the product, you should probably hold on off writing the story until you do.
A great technique to capture insights about the user and customer is to work with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. They usually consist of a name and picture, relevant characteristics, behaviors, and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product.
A User Story is supposed to be a lightweight technique that allows project to progress without being weighed down by the clunk of tedious writing. They are not a specification, but a collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation. The Product Owner and the team should discuss them together. This allows you to capture only the necessary information to reduce overhead, and accelerate delivery.
A word of caution: You shouldn’t be relying on User Stories alone. Creating a great user experience requires much more. While User Stories are helpful in capturing product functionality, they are not well suited to describe the user journey or visual design. You can complement User Stories with other techniques such as story maps, workflow diagrams, storyboards, sketches, and mockups.
Top Mistakes in Writing User Stories
- Too Formal or Too Much Detail. Product Owners with good intentions often try to write extremely detailed user stories. If a team sees a story at iteration planning that looks like an IEEE requirements document, they’ll assume all the details are there and will skip the conversation.
- Masquerading Technical Tasks as Stories. Much of Agile’s power comes from having a working increment of software at the end of each iteration. If your stories are really just technical tasks you often don’t end up with working software at the end of each iteration. You also lose flexibility in prioritization.
- Skipping the Conversation. Stories are intentionally vague before iteration planning. If you skip the acceptance criteria conversation, you risk moving in the wrong direction, missing edge cases or overlooking customer needs.
Pentalog hosts knowledge sharing events so that people can learn from each other and become better IT specialists. Join our community to stay up to date!
Who is Responsible for the User Stories?
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. They are the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items.
- Ordering the items in the Product Backlog to best achieve goals and missions.
- Optimizing the value of the work the Development Team performs.
- Ensuring the Product Backlog is visible, understandable and shows what the Scrum Team will work on next.
- Ensuring the Development Team understands items in the Product Backlog.
The responsibilities of a Product Owner are not limited to those just listed. They are far more complex and go from defining the product’s vision or performing marketing research to analyzing user feedback or managing the stakeholders.
Watch this video for a summarization of all the responsibilities of a Product Owner in Agile.
Teamwork makes the Dream Work
The role of a Product Owner within an agile project is crucial to a product’s success. It’s not unusual in the outsourcing industry for a Product Owner to come from a different professional background when compared to this role.
In most cases, the assigned Product Owner is someone who knows the business very well, understands the needs of the customers, and is a specialist in a particular domain or a marketing person. This type of background is very useful, but additional techniques must be mastered by the Product Owner in order to succeed in all the aspects of such a complex role.
As the Scrum framework envisions, Pentalog is offering an experienced Scrum Master/Agile Coach for each project to handle the coaching activities necessary in preparing the Product Owner for their role, including writing effective user stories. Check out our team!
Find out if the Product Owner should come from the client or the provider and discover the Product Owner’s responsibilities!
Interested to become a Product Owner? Test your skills!
