Tips for Writing Effective User Stories: Approaches to Writing User Stories | Part 1 of 4
Receive free IIBA updates and exclusive content!
User stories are the most common way of representing requirements on an Agile project. And it’s often a responsibility that falls on the business analyst or product owner assigned to create them. IIBA® recently had guest speaker Tomette Kirk, Manager, Business Systems Analysis at Humana, Inc discuss the 5 parts of a user story and her tips for writing effective user stories.
In the webinar, we received many questions from the audience asking for additional details on topics she covered as well as challenges they had in writing their own user stories.
Over the next few blog posts, we will answer those questions with each post focused on a theme:
- Approaches to writing user stories
- Format and structure of user stories
- Requirements and user story details, and
- User story and related techniques
Approaches to Writing User Stories
The approach to writing effective user stories is the same regardless of the role that is writing user stories (for example, Business Analysts, product owners, UX researchers and so on). You need to answer who does what, why, and when. A great exercise example from a User Story writing workshop is having the Subject Matter Experts, or the Actor users write what it is they do or need to do with the new solution. Using a card or sticky note they write, “As a <role> I must be able to <do> <something> so that….” As the Business Analyst or Product Owner you can take those notes and tweak them into formal, well-written user stories. When the team refines (grooms) the story, the team can also come up with additional Acceptance Criteria.
Q: I am currently the only business analyst working for our organization (big university in South Africa) and would like to introduce more agile methods in order to do things faster and more efficiently as there is too much work for only one business analyst, but budget constraints prevent the organization from appointing another business analyst.
A: Doing Agile and being agile are two different things. When a team ‘does’ Agile, they are employing a certain Agile methodology such as Scrum, or XP. BEING agile, means only doing enough analysis and documentation that adds VALUE, not simply doing the whole Big Requirements Document because someone said so, or it’s always been done. Are people actually reading everything and digesting it? Doubtful. So just do enough. It is too much work for one person. Streamlining the work is one way to help both yourself and the team.
Q: How do you explain to stakeholders that Agile is not about "not writing the requirements"? The issue is that sometimes people say that they are Agile so they don’t want to write User Stories.
A: An Agile methodology – Scrum for example – still has a product backlog which is comprised of user stories. In the product backlog they may not be refined yet, but then when a chunk of stories comes into the Sprint backlog, they should be formalized and finalized. Maybe explain that user stories are a simpler (though not simple) way to capture requirements
Q: I work in data warehouse/BI. We struggle with creating user stories that are small enough to fit in a sprint and that are independent because we are heavy in data development. Any advice on how to write valuable user stories that are small enough to fit in a sprint?
A: This is where breaking stories out becomes critical if you are able to identify the micro-parts of your process. If the work is going to span sprints, you may want to create User Story Part 1, Part 2, Part 3. Or suggest that you have a combined Sprint One and Sprint Two (a four-week initiative instead of a two-week one). But these are simply ideas. It’s hard when you are doing heavy duty back-end work.
Q: In product-based companies who should write the user stories?
A: Although “anyone” could write user stories, there is an art to doing so. Generally, if you are a product-based shop, you’ll have a PO (product owner) who should be responsible for writing stories. But there’s definitely a role for a business analyst to do it too. There is a technique, a Story Writing Workshop, where actual users write their own stories on a 3x5 card or post-it note.
Q: In the webinar you shared that we shouldn’t include “need” stories. Can you please explain why?
A:“Need” tends to lead to design requirements, such as “I need a button” or “I need a thing.” The original intent of the agile user story template: As a <role>, I <need to (or want to)>, so that <reason> was to explain TO DO activities, but the “to” gets left out, and we get back to needing a feature, instead of needing to do something. Must do or Must be able to do avoids that trap.
Q: We don’t have a designer for our Agile project. User Stories go from me to Dev Team. How can I create good user stories, while providing the Dev Team the design information they need? The client wants an email, not any kind of notification.
A: It’s ok to recommend a design suggestion, especially if the client has a preference. You just don’t want to “paint yourself into a corner” by designing in your user stories. There may be a cooler way to fill the need. I recommend adding a sentence after the user story that says, “Client would like to receive an email when <something happens>.”
Q: What is the best way to approach writing user stories for APIs?
A: Think about the dependencies and non-functional requirements or performance requirements – these play a key role. APIs could be written AS the actor, for example: “The API must include <this data> in the response so that…” Consider the final goal or the final benefit that comes from the API – what is the desired outcome of the API connection? Need to write stories that involve the data analysis of the end points as well, that may include the data elements of the API. Need to know the two end points, who is pulling the data, and who is publishing the data. How is the data being used, for example, for reports, dashboard, who is accessing the data?
IIBA Members, login to watch the Writing Effective User Stories webinar on-demand. Stay tuned to IIBA’s Analyst Catalyst blog for the next post in the series, where we’ll dive into dealing with user story format and structure.
Only IIBA Membership gives you exclusive access to IIBA’s KnowledgeHub. If you are not yet a Member, join today to become a Member of IIBA and start experiencing all the benefits.
About The Author:
Susan Moore is the Community Engagement Manager at the International Institute of Business Analysis (IIBA). She is a Product Management professional with more than 20 years’ experience in the Finance and Insurance industries. Before coming to IIBA, Susan worked in Business Analysis and Project Management roles, incorporating business analysis leadership and agile practices into the business analysis teams where she worked. Susan also writes on these topics at TheVirtualBACoach.com. Susan holds several business analysis and Agile certifications including IIBA’s Agile Analysis Certification.
