User Stories: Managing User Stories in Scrum Framework | Jimmy Mathew | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

User Stories: Managing User Stories in Scrum Framework

teacher avatar Jimmy Mathew, Agile Consultant

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

4 Lessons (34m)
    • 1. Course Introduction

      1:25
    • 2. User Story Basics

      15:07
    • 3. Managing User Stories

      16:51
    • 4. Outro Our Courses in SkillShare

      0:55
  • --
  • 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.

126

Students

--

Projects

About This Class

*Updated as per the latest Scrum Guide, Nov 2020. We have updated the course content as per the changes made in the latest version of the scrum Guide(TM)

This course discuss how user stories are handled in scrum framework. This course discuss topics including, User Story Mapping, Techniques foe Creating, Splitting/breaking down, Ordering, Estimating user stories, Acceptance Criteria, Definition of Ready, Definition of Done, etc.

A user story is a requirement written in an end-user perspective. A user story describes functionality that will be valuable to either a user or purchaser of a system or software. These are written in the perspective of customer. It reflects what customer expect from or want to do with the product.

This course has some common modules/sessions with our other courses "Agile Requirements: Managing Requirements in Scrum Framework" and "Scrum Product Owner: Agile Product Ownership with Scrum". Also a few topics from our scrum training.

***************************************************

 

Topics covered are listed below.

User Story Basics

          Introduction

          User Stories

          Acceptance Criteria

          Definition of Ready

          Definition of Done

          Estimation

Managing User Stories

          User Story mapping

          Splitting user stories

          Ordering Backlog Items

          Release Planning

We will start with the basics. Then there will be a details discussion on user stories, acceptance criteria, definition of ready for a user story, definition of done for a user story etc.

Then there will be a detailed discussion on different methods of maintaining the user stories. We will discuss, user story mapping, different approaches for breaking down the epics or user stories, different methods used for prioritizing etc.

Meet Your Teacher

Teacher Profile Image

Jimmy Mathew

Agile Consultant

Teacher

Around 15 years in IT, 7 years of Agile experience, playing various roles of Agile Coach, Scrum Master, Trainer, etc.

Publications  

Book: - Scrum Tales: Stories from a Scrum Master's Diary  

Book: - Agile Life: Understanding agile in a non-software context  

Certifications

 

.      ICP-ACC - ICP Agile Coaching   

·      CSP – Certified Scrum Professional  

·      CSM – Certified Scrum Master  

·      SAFe - Scaled Agile Framework-Agilist  

·      PSM1 – Professional Scrum Master  

... See full profile

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.

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.

Transcripts

1. Course Introduction: Hello and welcome to this course on user stories. Here we will discuss how user stories are handled in Scrum framework. A user story is a requirements are written in an end-user perspective. A user story describes functionality that will be valuable to either a user or a purchaser of a system or software. These are written in their perspective of customer. It reflects what customers expect from or want to do with a product. This slide shows the topics that we cover as part of this course. We will start with the basics. Then there will be a detailed discussion on user stories, acceptance criteria, definition already for our user story, definition of done for a user story, etc. Then there will be a detailed discussion on different methods of maintaining the user stories. We will discuss user story mapping, different approaches for breaking down the epics or user stories, different methods used for prioritizing, etcetera. 2. User Story Basics: Hello, welcome back. We will start our discussion. We will start with the basics. A user story is a requirement written in end-user perspective. A user story describes functionality that will be valuable to either a user or a purchaser of a system or software. These are written in the perspective of the customer. It reflects what the customer expects from or wants to do with the product. Items in the product backlog, usually written in the form of user stories. It usually takes this form. As a user, I want to do something so that I get this benefit. For example, as a user, I want to see the list of all emails received so that I can select one for viewing. The three Cs for a user story. Cod, conversation. Confirmation. Cod indicates that they use a story should be smaller law for a single card. Conversation talks about the detailing pot. Setting will be a result of Father discussions and collaboration. Or details will be attached to add it to the user story. As we go along. Confirmation indicates when we can confirm that the user story is successfully implemented. Usually it may take the form of the acceptable criteria. Spike as a story or task aimed at on answering a question or gathering information, rather than at producing shippable product. The pop is, is the gain, the knowledge necessary to reduce the risk of a technical approach. Better understanding of a requirement or increase the reliability of a story estimate. Larger uses. Stories are typically referred to as Epics. Epics generally take more than one or two sprints to develop and test. They usually brought in scope, short-term details. It must be split into multiple, smaller stories before the team then welcome them. In short, we can say it's allowed user story. A theme is a group of users stories that share a common attribute. They are grouped together for convenience. For example, we can have a theme, communication. O stories related to customer communication can be grouped and tracked under this, themes are often used to organize stories into releases or to organize them so that barriers sub teams can welcome them. A good user story should follow, invest. It stands for independent, negotiable, valuable, estimatable, sized, appropriately, and testable. Independent implies the user story should be self-contained in a way that there is no inherent dependency. And another user story, it should be negotiable. Stories are not contracts, leave room for discussions. More details will be added or a changes as more knowledge is available. A user story should be valuable to customers and uses, not developers. It should be written to reflect to user o client perspective. A user story must have enough details to estimate the required levels. Predictions are based on these estimates, so we should be able to estimate them. A user story must be smaller, love to complete in one sprint. Lodge stories should be split into smaller ones. A user story must be testable. The confirmation attribute that we have discussed earlier must be stated clearly. The user story should be small enough to be implemented within one sprint. But it is up to the scrum team to decide what extent the story should be fine grained based on the nature of work. And epic in general, can be considered as a large user story that needs to be broken down into smaller User Stories. Scrum teams will decide to what extent the story should be fine grained. Based on an H0 of work. Maybe we can consider an epic as ready when ooh uses stories derived from it already. Acceptance criteria is the sets of pre-established condition is that the product increments are satisfied to be accepted by the user, which was also known as conditions of satisfaction and will be provided by product owner. It can include functional and non-functional elements. A should be expressed in simple language without leaving room for any ambiguity. Acceptance criteria is written in simple language. It defines the conditions of success, all conditions of satisfaction. It provides clear story boundaries. Acceptance criteria removes ambiguity by forcing the team to think through how a feature or a piece of functionality will walk from the user's perspective. It provides a checklist or template or things to consider for each story and establishes the basis for acceptance testing. Instead of a simple user story, as an admin, I want to create uses. So that's I can grant access to the system. Acceptance criteria for this user story can include items like an admin can create user accounts. No other road is able to create uses. An admin can create user with user name, email, id, mobile number. System displays a message or any of the above fields are missing and use it as an all created system sends an email to the user wants the account is created, the list can go on. Definition of ready for a user story confirms that the user story is ready for implementation. This can include items like story defined and the business value is clearly articulated. Story has been assigned with the right amount of story points. It is estimated. Story is clearly undisturbed by the team. Acceptance criteria are clear and testable. Dependencies are identified and no external dependencies. We're broke the story from being completed. Is this test dates are required to test the story has been identified before minced criteria, if any, are defined and measurable. The story is small enough to be comfortably completed in one sprint. Definition of done for a user story is as sets of pre-established conditions for confirming the same as done. It is not the same as acceptance criteria. At meeting the acceptance criteria will be an automatic selection to the list. It because it's, it has many aspects like organizational processes, standards, legal requirements, etcetera. It is agreed upon the developers and the Product Owner. It will be inspected in regular intervals and improved. It is not a frozen document. A can be defined for Sprint and release as well. Checklists confirming if the sprinter release is done in all aspects. Consider a simple user story. As an admin, I went to great uses. So that's I can grant access to the system. Items in a definition of done can include user stories, acceptance criteria, and reviewed by the product owner. O code changes are reviewed as prescribed, a quantity manual and major findings are closed. Code changes. A check to XYZ brunch. The list can go on the aisle. Different estimation techniques in use. Traditionally we use techniques like lines of code, function points, use case points, et cetera. In Agile, we use techniques like storypoints, T-Shirt sizing, ideal days, et cetera. Ideal days is an absolute estimation method. It estimates how long something would take if it's all you worked on and there are no interruptions for the work. You have everything you need for carrying out the work. In Scrum, Task level estimates are usually done in ideal hours. Relative estimation consists of estimating something no separately and not an absolute units of time butts in comparison with one another. It is also done by grouping of items of equivalent size. In short, estimation is done in relative way in comparison with one another. T-shirt sizing and storypoints are two examples of relative estimation. Story points is an arbitrary measure used for Scrum teams. These use used to measure the effort required to implement a story. It is a relative measure. It has DOM by comparison. It estimates how long will it take considering many factors like complexity, uncertainty, and risk, et cetera. It is a faster way of estimating. People who do the walk is responsible for making this estimate are frequently used scale is the Fibonacci series. Story Points are a unit of measure for expressing the overall size of the user story, feature or other piece of work. The number of story points associated with the user story represents the overall size of the story. When estimating with story points, we assign a point value to each of them. The other characteristics are, the estimation scale should be non-linear. Frequently used scale is Fibonacci series, etcetera. We use a set of numbers that makes sense. We may use a modified Fibonacci series as well, like 012358132040, etc. Largest stories. Epics can have a range like one hundred, two hundred, etc. Story pointing is a relative estimation method. It requires a referral point to do the estimates. Experience teams may have a clear understanding as to what story point is meant for them. This is from their previous story pointing. When we do it for the first time, we need to create a base. A story of a reasonably small size will be selected and assigned one or two points. Other stories will be compared with this to find its size. Some companies advocate considering certain hours of effort as a story point. This is a controversial approach and against the sense of story pointing. Planning poker is a method, tool or an activity for estimating using story points. Usually follows the below steps. Bus. The product owner provides a short overview of the story to be estimated. The team discusses to clarify assumptions and risks, and the outcome of the discussion is updated in the user story, each individual is given a set of cards with the values that are used. Usually the cards with Fibonacci numbers. Each individual selects a cod representing the estimate and lays it down. Everyone shows that cod simultaneously by turning them over. If there is a difference, people with high estimates and low estimates, I'll give him a chance to clarify that estimate. And then the process repeats. What should we do if there is no consensus and planning poker? Participants with estimate at extreme ends will explain the logic behind the estimation. Product owner clarifies if there are any points or wrong understanding. Once the story and expect to work is clear, team will estimate again. This process can repeat, but can't go on indefinitely. If the team fails to get an estimate that indicates there is no single shared understanding on the story, although work related to it, the story should be pots with the grooming. T-shirt sizing is a way of relative sizing. By comparing stories, you can put them in buckets of extra small, small, medium, large, and extra large. Estimating or relative buckets is easier than estimating absolute time or effort. Estimation is not a one time activity. At the earliest stages at Epic or feature level estimates will be a high level. Once requirements reached the level of user stories, we will do a relative estimation with story points. While doing this sprint planning, we will create tasks for each story which will be estimated using ideal days or ideal hours. 3. Managing User Stories: Hello, welcome back. User Story Mapping is a visual representation that helps to define the work that is required in the product. It is a visual way of creating product backlog. It can be used in finding out the user stories for the product in a structured way. We are approaching this activity from a user perspective. It helps in identifying the user stories and grouping them. The output from this exercise can be used in release planning. Let's discuss this using an example. Consider an application for making hotel reservations. One of the goals of this product will be a user should be able to book a hotel room online. If we further look into this, there are many activities involved in this process. Searching for hotels is one of them. There are many tasks that the user may perform as part of this activity, like search on date and location, assault based on price, a filter on user ratings. If we convert them to use a stories that can be many stories like as a user, I want to search based on the date and location. So that's I see the availability. As a user, I want to sort the list on price. So that's I can select a room. As a user, I want to filter the list on rating. So that's I can select a room like this. We can analyze the different features of the product. This brings in a shared understanding among all parties involved. This helps him breaking down important features of the application. As we have all main stories on the board, doing a relative estimation becomes easier. It helps him prioritization and release planning. We split the stories based on functionality, not based on technical layers or stories we'll cover or technical layers required for its implementation. This approach is called slicing the cake. In other words, we should not split user stories based on architectural layers. It should be done based on functionality. Each slice that have a part of all the layers. There are different approaches used to break down epics or user stories. A few of them are listed below. Workflow steps, business rule variations, major effort, simple or complex, split using crud, which is create, read, update, delete operations. Variations in data, data entry methods. Spike first, split at basic exception path differ performance. In the coming slides we will see examples with these approaches. Always remember this slicing the cake approach that we have discussed earlier. We should not split user stories based on architectural layers. It should be done based on functionality. Each slice should have a part of all the layers. Workflow steps. When a user story involves work flow some kind, the item can be usually broken down into individual steps. Consider the user story. As a customer, I want to shop online, so that's our received my products at home. There are different steps involved in this process. We can split the story based on them to among the resulting stories can be, as a customer, I want to log in to the online stores so that I can shop. As a customer. I want to view my shopping cart so that I can do a checkout. Business rule variations. When a user story contains a process that with different business rules, we can split it based on those rules. Consider the user story. As a customer, I want to pay online. So that's our received my products at home. There are many concerns in this process. Two among the resulting stories can be, as a customer, I want to pay using credit card. So that's I can shop online. As a shop owner, I want to view the payment status so that I can process the older major effort. If the user's story involves a major functionality and its variations, we will break up the variations and implement the major effort first, consider the user story. As a customer, I want to pay online with visa and Mx or MasterCard's. So that's our received my products at home. The major effort here we'll be using the payment infrastructure. Once it is in place, other cards can be added with less effort to among the resulting stories can be, as a customer, I want to pay using Visa credit card. So that's I can shop online. Once it is implemented, we can extend it. As a customer, I want to pay using MasterCard. So that's I can shop online. Simple or complex. Starts with a simple implementation and add more functionality later. Consider the user story. As customer, I want to search for hotels, so that's I can make a booking to among the resulting stories can be, as a customer, I want to search with a date and location. Sonata can do a booking. Once this is in place, we can add more features. As a customer, I want to see options in adjacent dates so that I can see and select the best one. Split using crud, create, read, update, delete operations. A user story can be split using different operations such as create, read, update, or delete. Consider the user story. As a customer, I want to create my profile to among the resulting stories can be, as a customer, I want to create my profile with basic information name, and email. As a customer, I want to update my profile so that I can add more details and variations in data. A user story can be split based on the data that the operation uses. Consider the user story. As an online customer, I want to search for laptops, so that's I can buy them online. To among the resulting stories can be, as an online customer, I want to search for laptops with make and price, so that's I can buy them online. As an online customer, I want to search for laptops were process a type and RAM. So that's I can buy them online. Data entry methods and imput form can be filled and saved using different ways. The first menu then automated. Consider the user story. As a customer, I want to search for hotels, so that's I can make a booking. Here we will start with a simple implementation and make fancy user interface later. To among the resulting stories can be, as a customer, I want to search with date and location so that I can do a booking. Now we will enhance the experience. As a customer. I want to select location using map, so that's I can search for hotels. Spike first approach, when a user story has a complex functionality, challenging technology concerns that the team is unsure about. Do an experiment first, consider the user story. As a customer, I want to pay online. So that's our received my products at home trait to Spike for experimenting with online payment gateways. This will reduce the unknowns regarding the functionality. Great user stories based on the result of this experiment. Split at basic or exception path. Start with a simple implementation and go to exceptional cases. Consider the user story. As a customer, I want to search for hotels, so that's I can make a booking. We will start with a normal, simple flow to among the resulting stories can be, as a customer, I want to search with dates and location. So that's I can do a booking. Now, an advanced feature. As a customer, I want the system to identify my current location. If I leave it blank so that I can search for hotels in my location. Defer performance, make it work, then make it fast, make the functionality work before going for optimization. Consider the user story. As a customer, I want to search for hotels. So that's I can make a booking to among the resulting stories can be, as a customer, I want to search with date and location so that I can do a booking. As a customer, I want to see the search results within two seconds. So that's I can book foster. There are many other methods used for breaking down uses stories, including. Based on test scenarios or test cases, based on rows, based on acceptance criteria, and based on external dependencies, et cetera. Always remember the final decision on the odour is from the Product Owner. However, other roles can influence these decisions. Product Backlog Items are ordered to provide maximum benefits to the business by delivering high value items earlier than later. Factors that influence these decisions are the business value, market demand, teen capability, risk, dependencies, etc. There are different methods that exist for the prioritization or product backlog. Moscow analysis. In this method, a list of requirements or user stories are categorized into the following four groups. Must have describes a requirement that must be satisfied in the final solution. For the solution to be considered, XXS should have represents a high priority item that should be included in the solution if it is possible. This is often an important requirement, but one which can be satisfied in other ways, if absolutely necessary, could have, describes a requirement which is considered desirable but not necessary. This will be included at time and resources permit won't have represents a requirement that stakeholders have agreed will not be implemented in a given release, but maybe considered in the future. Poka method. This is similar to planning poker. It is a quick and easy method to group items as per their relative priorities. Categories used here can be very high priority, high priority, medium priority, low-priority, very low priority. The steps are similar to that of planning poker. Oh, participants are giving cards representing these values. We can use another sets of values like high, medium, and low. That's his prioritizing using only three categories. Fast. The moderator presents the backlog item to be prioritized. He clarifies a requirement and each participant selects his or her cod. Oh, participants show that selection at the same time. If there are any differences that will be discussed and the process continues. Bidder feature. This is kind of a cumulative bidding method. Oh, participants are given the same amount of money, say a $100. The aim is to distribute this money among the backlog items under consideration. The moderator introduces all the backlog items to be prioritized. After that, each participant distributes the amount among these items based on his take on the priorities. Once this is done, the backlog items are prioritized based on the total amount each item received. There are many other methods used for prioritizing the backlog items. They include methods like Canaan modal, stack ranking, weighted shortest job first, which is ws j, f by a feature, etcetera. Whatever be the modal used in the final decision on the odour is from the Product. Owner. Planning is done at different levels in the Scrum. It all starts with a product division. We will have a high level plan at the release level. Every sprint starts with a sprint planning meeting. Every day, develop developer elaborates and plan their activities for the next 24 hours during daily Scrum. A few more points to note here. Ah, planning is not a one time activity. We inspect and adapt the plan has more knowledge is available. Agile plans or adaptive? No predictive. We adapt the plans to the changes. Plans will change as more knowledge is available. There will be a high level plan at the release level based on what is known. But this is not a frozen contract. This gives an overall view of how the product will evolve across iterations. It is a high level plan for multiple sprints. This reflects expectations like which features will be implemented and when. Velocity helps us in refining the release plan, the current size of the product backlog and the velocity will give as the number of iterations required are repeat. This is based on what is known so far. We have already seen this image. We will add it again for the completion of our discussion. Based on the predictive velocity, we can map the stories across different iteration output from the story mapping exercise priorities and dependencies will play a crucial role in this mapping. This activity can be done as a continuation of the story mapping exercise. 4. Outro Our Courses in SkillShare: We would like to provide an overview of our course is on the the the the the the, the opinions.