Tips for Writing Effective User Stories: Approaches to Writing User Stories | Part 4 of 4
Receive free IIBA updates and exclusive content!
Writing effective user stories is part understanding their structure as well as understanding the processes and techniques that support user story development. In this post Tomette Kirk answers questions on user stories and related techniques.
Q: What’s the difference between an EPIC and a user story? When do you use an EPIC vs a User story? Also, do user stories need to be connected to an EPIC?
A: There’s generally a hierarchy of requirements. Epics are very high level, very broad in scope. Next are Features, which are groupings of like functionality. Finally, you have User Stories which are the details for building and testing. User stories should be connected to a Feature, Features are connected to Epics.
Epics are realized by Features. Features are realized by User Stories. So, the Hierarchy would be:
- Epics
- Features
- User Stories
- User Stories
- Features
Q: How would you differentiate an EPIC Story from a User Story, in the sense of how much can bubble over from an EPIC on to the User Story? For example, I have a requirement for different tasks in a sub-level process within a high-level process and my user goals are similar for most of these processes. In this case, I have mentioned most of the Why's within the EPIC, therefore how can I describe the User Story without repeating whatever I have mentioned in the EPIC.
A: I would point to an Epic template that is recommended by the SAFe® community. Also remember, most of your developers aren’t going to work off of the Epic, but use the story. So, if there are details in your Epic that apply to your story, they should be repeated in each individual story. If you have details in the Epics that relate to stories, your Epics are probably too granular and should be pulled up to a higher level. Epics are very broad, very high level. Features are lower level but span across multiple stories. Stories should be independent, so the “Why” should be pertinent only to that story.
Q: How do you determine how many points your user story has? What's a "point" defined as?
A: One story point is the smallest chunk of work the team has. Then twice that size would be two points. Etc... Story points are more about effort than hours, Small, Med, Large, X-large. It’s more of a gut check for how much effort the story will take. Remember to include the development and testing in story sizing.
Q: How do you estimate Business Analysis effort to write user stories?
A: Business Analysis effort is different than story points. In BABOK® Guide’s Knowledge Area “Business Analysis Planning and Monitoring,” it talks about what is needed to write user stories – interviews, activities, and actual writing time. That’s different than what effort it will take to build and test out a user story.
Q: Isn't it a better approach to talk about a certain effort instead of 4-5 hours = 1 story points?
A: Hours are a ‘guideline’ if you’re stuck, but story points are EFFORT, Small, Med, Large, X-large, XX-large. As mentioned in previous questions the answer, it’s a gut-check, a poker estimate. And your developers and testers should be at the table when estimating. This estimating exercise is done by the TEAM not just the Business Analyst.
Q: Are there any rules/best practice around splitting user stories up?
A: Consider what can fit into a sprint, or what one person can accomplish to equal one user story. When you start getting too many Acceptance Criteria, see if there’s a theme that you can break out into two stories. It may be a small part that you break out. Use your developers for advice on how to break out the work.
Q: What’s the difference between the User Context Diagram and the User Story?
A: A User Context Diagram takes into account ALL the actors that are touching the solution, whether providing input or receiving output. Each actor will be the star of one or many user stories. I like creating a User Context Diagram to show pictorially all the user stories in one diagram. It can indicate simplicity and complexity. Every arrow is one user story. So, the final picture would probably have multiple arrows going from the actor to the solution for each activity the actor is going to perform. Give it a try!
Q: How do you address the WHY (5 Why’s) exercise with groups?
A: Whenever I use the (5 Why’s) exercise, I always announce that I’m going to do it to get a little deeper. I don’t just spring it on them in conversation. I introduce it, confessing that either I just did a “stopper” such as “Got it,” or “I understand” which stops the dialogue, OR that I’m having trouble getting to the reason behind the ask, “I’d like to do a five why exercise to dig a little deeper.” Another way is to think of alternative ways to ask “why” such as, “Can you tell me more about <x>?” or “That’s interesting, what makes you say/do/ask that?” Keep the conversation going as long as you can. It’s true, some people become defensive when you ask “Why?” Work around that if you know your team is sensitive to it.
Q: What if there are behind the scenes processes behind the product ex. Reporting - shouldn’t Business Analysts be involved to identify these things?
A: Business Analysts are great at identifying these processes! The WHO in your story is the actor that is going to use the report. That’s the focus (actor) of your user story. You can put details in the Acceptance Criteria about the fields, and maybe even the data descriptions (alphanumeric, character length, etc.) with the help of a database developer, depending on how specific your team needs. Another important part of this story is WHY? Why is the report needed? Who’s going to use it and Why do they need it?
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.
