Scrum Product Backlog Management - The Essentials

1. Introduction: Hi, I'm bad. Hell. And this is Graham Product backlog management. The essentials. The theory Off backlog management is defined in the scrum guide. I put a link to it in the about section off. This class is the practice that can get tricky sometimes. So instead off just teaching you the concepts off bad clock management. I would walk you through a consistent example from the product vision to discovering high level stories to using a technique called story mapping to derive the more detailed stories . And I will also teach you what to do in the scrum events. As this is an intermediate level class, you should have a basic understanding off how agile software development and scram works. If you need a short re care, please watch my class agile and scrum for beginners. And now, without further ado, let's begin 2. The product vision: before you create an initial product back lock, your team should have a shared vision off the product to develop. While a product vision is not an official artifact off scrum, it can help set the gold that everybody agrees on. Customers, management, the product owner and developers. A good vision motivates the people working on the product, and it helps make scope decisions later on what to put into the product and what not. That's why it is relevant for bad clock management as well as Ken Shaver, one off the father's off scrum. Once put it, the minimum plan necessary to start a scrum project consists off a vision and a product backlog. It's the product owner who leads the effort to come up with a product region. It is created in close collaboration with the rest off the scrum team and other stakeholders. Since this is a class about clock, management will focus on a very simple former for documenting the vision, The vision statement. A more sophisticated former to create a product vision. It's Roman Pickles Product Vision Board. You'll find a link to it in the about section off this class. Let's say your company wants to develop an online portal for booking flights specifically targeted at frequent flyers. Your vision statement might read. Frequent flyers fly often cheap and comfortable. In that statement, you recognize key properties off a vision. It should be short that enables you to focus your development efforts. It should point out for your target. User groups are, in this case, frequent flyers, and it should state what the users needs are that are dressed by the product They want to fly, often cheap and comfortable. Once you have created a product vision, you should make it visible to the stakeholders, for example, printed out and hang it in your team's room. Once the stakeholders have agreed on a product vision, you can start creating an initial product backlog. 3. High level user stories: Once you've got a product vision, you can start discovering heil every user stories based on your user's needs. Before I start with it, Here's a disclaimer. There are many ways to manage your product back. Look in this class. I will show you my preferred way. While I am convinced of it. Please experiment with it and find your own way. That fits well. Let's revisit the example. Vision Statement. Fly often cheap and comfortable. What other needs hidden in it. If a person chooses to fly by plane, she usually needs to travel to a distant location. If she travels quite often, that can be become quite expensive. So she has the need to save money, either for herself or for the company she works for. And as she needs to organize trips, often, doing so should be comfortable. For example, the software should be easy to use, So why even bother to think about the needs off the users? Why not jump right into developing features? Well, when people use your software, they don't do it because they like a software so much or because it looks nice or is technologically advanced. They do it because it fulfills some lead they have and that will make the software successful. Another reason for thinking about needs is you want to compare solutions to each other. What is the best or cheapest solution for the user or your company that forfeits the needs ? What solution is the least effort and risk to develop Once you've got the needs, you can start discovering the high level user stories by the product owners responsible for the outcome. This is best done involving the whole scram team. A popular former for documenting the results is Azar User Group. I want the suffering to have a certain feature so that a certain need is fulfilled. Here are some examples As a frequent flyer, I want to book a flight so that I can travel to a distant location. Or I want to get a discount if I book often so that I can save money or I want to re book a flight easily so that the booking process is comfortable as you can see, the end off each off these sentences reflects the needs we identified earlier and in the middle. You see how the software for face this need some properties off. Good user stories are a good user. Story is written from a user's perspective, not a technical perspective to make sure you fulfill the user's needs use. The stories are short, as you've seen in the examples. That also means you leave out the details. At first you clarify the details later shortly before implementing the story. Stories are more about conversation than documentation, so you use them to discuss ideas in the scrum team and document just enoughto award for getting the results. So it shouldn't be the product owner alone who comes up with these stories. This is really ah whole team effort. 4. The initial product backlog: you need an initial product backlog as the starting point for scrum. Based on the high level stories, you can create the initial back look. I like a technique called story mapping to do that, and I show you how to use it by example. Let's revisit the high level stories. The first thing to do is to extract the features from the stories. If you do that in our example, you get three features book, flight, get discount and re booked flight easily. What would happen now in practice is that your scram t meets for a story mapping workshop. The team notices that booking a flight is the core workflow that everything else depends upon. So the team writes book flight on an orange sticking note. It's orange as it is, a user activity or, in other words, a workflow with multiple tasks to be performed by users. What do you use us need to do to book a flight? Let's say, to book a flight, a user needs to register or log in first, so the team hangs that sticky note on the left and subsequent asks toe the right off it. After logging in, she searches flights. Then she picks a flight. Then she enters payment information, and finally she confirms the booking. What about the other features you extracted earlier, get discount and re booked flight easily? The team's decides they should not be treated as user activities. But as he was our tasks. There aren't really separate work flows, so the team integrates them in the book flight activity. He is the new book flight activity, with all features integrated in any real world application. There will be more use activities, for example, run activity to manage the account. Orange sticky notes are ordered left to right in the sequence they occur, same as with the blue user tasks. Now that we've got the activities and tasks the so called backbone off the story map, we can start discovering they use our stories. Your team brainstorms what to do and arranges the stories below the backbone. You think about what to implement first for the book flight activity. What would be a minimum solution that shows you on the right track? Here's what the team comes up with. You can search for flights, but only the flights off a single airline. You can pick a flight by a simple click, and then you're directed to the payment. You can only pay with Visa and confirm it with a simple button press. After that, the developers will implement the log in for convenience. They will implement searching for another airline When the user picks off light, the soft specials details about it, and you can pay with another credit card. And finally, the developers will implement searching various airlines. The software calculates and shows the discount you can pay with several credit cards, and there's a whole page summarizing the booking details for you to confirm. As you can see, the logical excess determines three order off implementation stories at the top are implemented. First stories at the bottom are implemented last. Instead of building the software one goal, you build it up, a territory, flee and incrementally to reduce development risk. Once the team has built the stories on this map, they shipped the software to test use us to get feedback. If the software's where you open and there you are, you've created the initial product back. Look, no, you may be wondering, Isn't a scrum backlog of flat ordered lists? That's right, and it's quite easy to convert the two dimensional story map toe a one dimensional grand back. Look, you simply number the stories from left to right and top to bottom. That's the rank off your product. Back. Look. Items off course. You can shift things around horizontally. I prefer the two dimensional story map as a big rock fall as it is a nice overview off the things to be developed. 5. The product backlog in sprint planning: what happens to the product backlog? Has Sprint planning in Sprint planning at the beginning? Off the Sprint, the product owner discusses the stories at the top off the product backlog with the developers, the developers forecast how many they are likely to get done during this print. To be able to do the forecast. The details off the stories need to be understood well enough. They should be the result off a negotiation between the product owner and the developers, and they should be documented as acceptance criteria. Also, the story should be small so that the developers can show the progress they made in Sprint Review. There should be around 5 to 10 stories available for the Sprint. Furthermore, the team agrees on an overarching goal for the Sprint. The developers to the design and agree on tasks to implement the stories. Let's have a look at our top story from the example. Backlog. Search single airline. When the product owner meets the developers, she has a lot of ideas. The airline is fixed to United Airlines. The frequent flyer can specify source and target airport day off departure and return. How many other adults and Children will fly and which class they will fly in. The product owner wants the source and Target airport as auto complete fields and the day off departure and return to be picked from a calendar. In the discussion with the developers, it quickly turns out that this story is too big for a two week sprint. So the team starts to brainstorm what would be the simplest thing to do with this story? He is what the team agrees on. The airline is fixed to United Airlines Samos before, but the source and Target Airport are specified. A simple text fields without auto complete only the day off departure can be specified. So at first, only singer trips are possible. The user needs to enter the date in a simple text field. There's no calendar. Only one adult can fly that is fixed in the class is fixed to coach. On top off that, the developers create a simple wire frame to show what the page will look like. Off course. This story does not represent the final story that will be delivered to end users. It does not have to. It's part off the interactive nature off scram to refine the work that has been done. Sprint by Sprint. The team agrees on the Sprint goal to be able to book a flight off a single airline. To reach their goal, the team can stop discussing further details off the search single airline story. Now this will be done in the future, when the team has more knowledge based on the implementation and feedback off the stakeholders. Instead, the team starts to discuss the other stories needed to book a flight and defines acceptance criteria for them as well. But what about the original story? The full version off the search that will become clear when we look at the story map that is updated by the team and spring planning? The product owner decides to put that story at the very bottom off the map. Maybe you think now Why on Earth is dead? Remember that the goal off the release waas the shipper usable software to test uses to see if it's valuable. The product owner understands that to reach that goal, the U I does not need to be polished or perfect, so the story gets a lower priority. It's details will be defined in a future sprint when it will be implemented. When the team has discussed the stories for the Sprint. The developers are confident that they're able to deliver those stories. So the pull the stories into the sprint back look, they discuss the necessary development tasks to implement the stories. You can see them in the to do column. The development tasks are different from the user tasks in story mapping a development has could be create controller class A create screen design, be or create see service, and with that, Sprint planning is complete. 6. The product backlog during the sprint: what happens to the product backlog here in the Sprint. As I said before in Sprint planning, the developers put the top product by clock items to the Sprint backlog so they are removed from the product back. Look after Sprint planning the so called back lock refinement kicks in the product owner talks to users, developers and other stakeholders about the future off the product. The activities are similar to what we discussed for Sprint planning, with the difference that you don't plan the current sprint, you plan one or two sprints ahead. So, for example, in order to satisfy the stakeholders, the product owner may decide to implement payment with a different credit card first. In Sprint Review, the developers demonstrate the working software they build uring the Sprint, the product owner, the developers and other invited stakeholders discussed what has been achieved and what should be done next. As a result, off this, the product backlog may change. For example, in the first sprint, the developers got the search down. They also got the payment on because they could reuse it from another product. But they did not manage to actually book a flight with another airline that turned out to be more challenging than expected. The product owner has a choice. Completely discard the story or put it back in the backlog at a certain position, maybe with changed acceptance criteria. In the example, she decides that booking a flight with another airline should be implemented in the next sprint as it is part off the core functionality. And that's what you do to the product backlog during the sprint. 7. Conclusion: Hey, you finished all the videos? Congratulations. Off course. This has only been an overview. So if you have specific questions, please let me know. In the community section off this class, maybe you even have ideas for future classes I could teach. So if that is the case, please let me know as well and not to forget the class project. The assignment is quite simple. Create a simple story map and uploaded to the project gallery. So that's it for today. I hope to see you in another class off mine CIA.