How to Write Effective User Stories (Product Management 101) | Gemma Curl | Skillshare

How to Write Effective User Stories (Product Management 101)

Gemma Curl

How to Write Effective User Stories (Product Management 101)

Gemma Curl

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
5 Lessons (17m)
    • 1. User Story Course - 1 - Intro

      4:11
    • 2. User Story Course - 2 - User Story Characteristics

      4:10
    • 3. User Story Course - 3 - User Story Pitfalls

      2:44
    • 4. User Story Course - 4 - Practice User Story

      2:09
    • 5. User Story Course - 5 - Other Types of User Stories

      3:34
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

358

Students

2

Projects

About This Class

This class is an introduction to user stories. You will learn what a user story is, how to write effective user stories, the different types of user stories, user story pitfalls, and will practice writing user stories. The class project will be to write a user story for an example website and share it with the class.

This class is geared towards new Product Managers, aspiring Product Managers, and people who interact with Product Managers or sometimes serve the role of a Product Manager (e.g. software engineers, designers, QA testers, etc).

If you are already familiar with user stories, the components of effective user stories and user story pitfalls should still be helpful in strengthening your user story writing skills.

This class is filled with tips, tricks, and insights for all levels.

Meet Your Teacher

Teacher Profile Image

Gemma Curl

Teacher

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

1. User Story Course - 1 - Intro: Hello. Welcome to product management. 101 How to write effective user stories. My name is Jim a curl, and I'm excited to share some of my knowledge about writing effective user stories with you here today. To start with a little background, I'm a mom, wife and product manager. I'm currently working as a technical PM for a SAS company, but I also have experience in e commerce and media. I've consulted Fortune 500 government agencies. One. How to develop effective software products. Applying the best practices of agile software development, lean methodologies and user centered design. This course doesn't require you to have any background in product management. I will try to break down all of the concepts to their basic level so that anyone can pick up the information regardless of where they're coming from. This course was written to be tool agnostic. You can apply the lessons learned to pivotal tracker Jura cello or whatever tool you would like to use to track your user stories. The mangle is for you to walk away from this course with a strong understanding of what a user story is. What makes an effective user story what details should go and use your stores. And what are the various types of user stories? Let's get started. First off, let's define what a user story is. If you have any past experience with user stories, this cartoon may resonate with you at its core. Ah, user stories, the smallest piece of work that delivers user value. We expressed this work as a user story to convey the user's needs to the development team. It's important to note that on healthy teams, the user story isn't a requirement that is thrown over the fence. To developers, it's the start of a conversation with the entire team around what the user needs and how to deliver that. With that in mind, the user's perspective is key. When writing a user story, the typical user story format is as a blank. I want to blink so that blink you would fill in your target persona, which is the character that represents a potential users of your website or app. In the first blink, the action user wants to take would go in the second blink, and lest their desired outcome would go in the third blink, let's walk through an example. Let's say you are a product manager for Song Kick, a website that helps music fans find concerts for their favorite artists, will assume you've been working for some kick for a while, and I've already developed user personas, and one of them is the avid concertgoers. In fact, let's say the personas name is Craig. He attends 3 to 5 concerts a month, usually a 10 shows with friends, and he has several artists he faithfully follows. This guy has those attributes. He looks really happy at this concert. So let's say he represents our Craig persona. We've interviewed several Craig's and learned that they want to find the song kick brand on social media so that they can stay in the loop on company news. The designers on your team came up with the mock up attached, and you want to write a user story for this capability as Creek. I want to fund song kick on Twitter so that I can view company updates and news. It wasn't too bad, right? That was a really simple example, and you may be wondering why we only included Twitter and the user story. That's because the best practice for user stories is to make them small so that user value can be delivered to customers quickly. The Facebook feature can be added in a follow up story. In fact, in the next section we will take some time to discuss what characteristics could use your stories have. In fact, in the next section we will take some time to discuss what characteristics good user stories have. 2. User Story Course - 2 - User Story Characteristics: what characteristics do good user stories have? Let's dig into those streets. Bill Wake, a thought leader in the ADDER development community, came up with an acronym in best that could be used to remember the qualities of a good user story. The I stands for independent meaning users story should not overlap with other users. Stories. The N stands for negotiable. A user story is meant to be the start of the conversation. Additional details may be discovered that get added to the story as it is picked up. The V stands for valuable user story should deliver value to users and not just a stakeholder, developer, designer or product manager. The E stands for estimable. The development team should be able to provide a rough estimate of how complex the story is relative to other stories in the backlog. If the story is not estimable, maybe the developers don't understand its intention or more investigation needs to be done upfront. Perhaps it needs to be broken down further. Speaking of which, the S stands for small, the story shouldn't be so big that it is hard to plan and prioritize the T stands for testable. The story should be clear so that a PM contest the functionality once it is developed, and ensure that it is working as expected prior to delivering the story to users. In addition to the user story description, the asi I Want to so that portion that we previously discussed there are several other key components of a good user story. The title should be short and clear. The acceptance criteria should define what must be true for the story to be accepted after the development team delivers the work, meaning What must be true for a product manager to be able to say that the story works as expected? There also could be a need for resource is that provide additional context to the story. Business rules, designs, links, notes and content should all be provided so that developers don't have to look for this one working on the story. No, let's spend some time talking about acceptance criteria, a critical component communicating with developers. The reserve stories are really like using gherkin syntax for my acceptance criteria. What is gherkin? Well, cucumber is a tool that allows us to create automated software tests and an easy to write easy to read way Cucumber uses gherkin syntax to specify a series of steps that should be followed to test out software capabilities. Even if you're engineering, team is not using cucumber, gherkin is still helpful. Way to wear it. Acceptance criteria to ensure steps are clear, follow a logical sequence and could be tested via an automated test suite if desired. The gherkin syntax uses keywords to indicate the beginning of a step, which include given when and and then as examples. Scenarios can also be used when there are multiple use cases you want to address in a story . Let's take a look at a detailed user story for the example we previously walked through our title, This Crate Confined Song Cake on Twitter, Our Description s Creek. I want to find song kick on Twitter so that I can view company updates and news. Our acceptance criteria is given. I am on the home page of Song Kick than I should see. Follow us when I click the Twitter button. Then I should see the song kick Twitter Page knows provide additional information about the song kick Twitter page. You are ill. The fact that the Twitter page should open in a new window and designs are attached notice in the attached designs. The component being built in this story is clearly identified with a box around the link. Now that we've walked through what this full user story should look like, let's talk about some pitfalls to watch out for. 3. User Story Course - 3 - User Story Pitfalls: we talked about the characteristics of a good user story. Now let's spend some time talking about common user story pitfalls going back to our song kick. Example. Let's pretend we're implementing a search feature. As a user, I want to see a search bar so that I can type in bands that I want to search for. What are some weaknesses and how this story is written? For one, the user and the story is not clear. Song Kick probably has multiple personas that include ticket sellers, buyers and members of the support team. It's important to convey who we're building this story for. Also, what is the outcome of the search? People don't just search for the sake of searching. There's typically one or more outcome tied toe in action, and describing the outcome provides some insight to the developers on the user's motivation . Lastly, the story as it's written, it's not valuable to users. The story is written as if it's only delivering the front end component of the search box. A search box that doesn't show any results doesn't solve the users need. If this story were completed independently, the user would have no new capabilities Here's another story about search functionality. Ask Craig. I want to search by band, location and date so that I can find all of the concerts that interest me. This story is asking for a variety of capabilities all at once. It probably makes sense to have a conversation with the engineering team. Understand? If this story could be broken down into several smaller stories, maybe each search criteria would require a separate P I requests and could be delivered independently. We don't know without having a conversation with engineering to determine the best way to deliver value to users fast. Here's one more user story that provides search capabilities. As a user, I want to search for drink so I can find all of his concerts. The acceptance criteria reads. Given I am on the home page, then I should see a form input with five pixels with padding around the text. When I click in the form input, then I should see Ah, 111000 hex cold cursor. When I type in the text box, I should see Size 18 pixel fund and this user story. We're telling the engineers how to implement every single detail, including the HTML elements to use when you work with good engineers. Story should list the what but not the how allow them to use their expertise to determine the best way to deliver this capability. 4. User Story Course - 4 - Practice User Story: Now it's your turn. Let's ride a practice user story going back to our song kick example. We've interviewed several Craig's and learned that they typically come to song kick to buy tickets with specific artists in mind. And they often have a problem finding their favorite artists on the platform. One, Craig mentioned that he really loves going to see drink, and when he last came to the site, it took him 10 minutes to find the tickets. In fact, it took so long he just left the site and went to buy tickets someplace else because he had to get tickets fast. You've worked with design and development to come up with the potential solution, and as a team you've landed on this approach. A search bar needs to be added to the top navigation menu so that Craig can quickly find what he needs on song Kick. This is the design that was created by your team, uses concerts for an artist. Then they have the ability to see concert details or filter based on criteria on the left. If we go to the upcoming events filter, we see only the events for drink better in the future. There is also the ability to buy tickets and ta go events status to reflect that you are interested or going to the concert. The's screens have quite a bit of features, so let's write a small user story that will get our team started on this new search capability. Work on writing a user story that has all of the important components needed for your development team to pick up this work, then go ahead and click, start a project and share your story with the rest of the class. Remember to include all of the important features of a users story that we previously discussed well, look at an example of a potential user story for this capability in the next section. 5. User Story Course - 5 - Other Types of User Stories: we talked about what a feature story looks like. But there are other types of user stories that are also important to be familiar with and have in your toolbox. Bucks are important for describing a defect or aggression in application behavior. I like to start off bugs with the title, which should be clear and descriptive, like that of a feature story. I follow that with a description, which includes steps to reproduce the bug. Expected behaviour and current behavior note should also be provided with additional details, and resource is like that of a feature story. Another story type that you may need to use is a joy. Joyce represent work that must be done to aid the team's progress and working on the product, but don't directly provide user value. I tend to be a bit less structured and chores, but I do think it's important for the title to be clear and descriptive. In addition, it is hopeful for the description to explain why the work must be done. Ah, format I like to use is we need to X so that why epic servers and a theme of work and allow you to tie multiple user stories together. For example, maybe you are creating multiple user stories to represent the various filter options that the designers proposed for song kick. We could write a filter up it to represent that work, and those stories would be grouped together and easily tracked through their completion in an issue tracking application like Pivotal tracker or deer in the description I've used to standard as a, I Want to. So that's index in the example provided above, but definitely feel flexible in the structure here and usual works best for your context to summarize their variety of types of user stories that you were right as a product manager, although they served different purposes, they all should have short, clear titles and be descriptive enough that anyone on your team could work on that particular user story. Remember, user stories are the start of a conversation. They can and should be generated collaboratively with others on the team state. The why and what not the how let engineers determine the best way to implement a particular feature, provide the relevant information needed to complete the work. Don't make developers go hunting for things that you could have easily provided in the user story. Use Real examples of edge cases exist so that the whole team can be made aware of those scenarios visually. Format your stories so that they're easy to scan. Separate the core content of the story from the minor details so engineers can quickly jumped to the most important parts when needed. Also clearly defined the story scope in visuals that are attached. It's easy for additional features to be added if it's not made clear in the visuals that are attached. Well, I hope you enjoyed those. Use a story, tips and tricks definitely let me know if you have any questions about this. This is a topic on particularly passionate about, and if you have any feedback for me, definitely feel free to send me a message I would love to hear from you.