Why the Scrum Product Backlog Is Not Only User Stories And Is Not Prioritised
In today's let's talk about Product Owner stuff. Let's talk about how to order the Product Backlog. This is important because there are still a lot of misconceptions out there. There are still a lot of articles and YouTube videos that says that the Product Backlog is prioritized. According to Scrum Guide the Product Backlog is ordered instead of prioritized. There are reasons why the Product Backlog is ordered and there are multiple aspects that Product Owner need to consider when ordering the Product Backlog. So if you are curious what are the aspects that the Product Owner need to consider when ordering the Product Backlog don't go anywhere stay on this video. As written on Scrum Guide the Product Owner is responsible to order the Product Backlog and accountable for the value of the product. The order of the Product Backlog will reflect the roadmap and the value that the company will likely get from the product.
Before we talk about how to order the Product Backlog, let's talk about what's inside the Product Backlog. There's a lot of misconceptions in the market that the Product Backlog only consists of User Stories or just the features of the product. So let's find out what's inside the Product Backlog. According to Scrum Guide the Product Backlog consists of all of the work known to be needed in the product. The keywords here are all the work, which means other than User Stories and features, the Product Backlog also consist of but not limited to defects, technical debt, product architecture, technical specification, user experience design, non-functional requirements, urgent work from the CEO, hypothesis, etc. The other keywords here that we have to notice here are: 'known to be needed', which means the Product Backlog consists of our current assumptions. If you're interested to learn how to write your Product Backlog item other than User Story format, I have made a video on how to write the Product Backlog item using the hypothesis format. If you are interested to learn more about it click the link up here to watch the video. Another thing we have to keep in mind is the Product Backlog is ordered rather than prioritized. There is a reason why Scrum Guide chose the word order rather than priority, so let's learn more about it. First because semantically two items can have the same priority but no two items can be at the same order. Priority reflects the level of urgency and often times it can be very subjective. This is very important for Scrum Masters and Product Owners to know especially those who works in a very political and bureaucratic organisation because in that kind of organisation many people will just say that everything is high priority just to get their stuff done first. So that's why we don't use the word priority in Scrum. Secondly, because there are other attributes to consider besides priority. Some of the attributes the Product Owner must consider when ordering the Product Backlog are dependencies, the age of the Product Backlog item, the size of the Product Backlog item, perceived value, risk and also learning. Let's talk about dependencies between Product Backlog items. When talking about dependencies there are two types of dependencies that are business dependencies and technical dependencies. Two items may be on top of each other because it is dependent on one another. In the context of Scrum we strive to remove dependencies at technical level and make the architecture of the product to be loosely coupled as possible so multiple teams can work on the Product Backlog items independently. The size of the Product Backlog item is another attribute that is considered when ordering the Product Backlog. Many Scrum teams use story points in Fibonacci sequence or t-shirt size to size their Product Backlog items. Ideally on the top order are the items that has been sliced and refined as such it can be completed in one Sprint and on the bottom order we have all of the items that are coarse-grained. The Product Backlog items on the top order are refined and ready for the next two to three Sprints. The rest are coarse-grained and open for change.
In Scrum we do not slice and refine all of the Product Backlog items as that will be expensive and there is a risk that not everything in the Product Backlog is going to be needed. According to Scrum Guide awesome Scrum teams spent at least 10% of their Sprint to refine the large size Product Backlog items continuously. Slicing and refining is a collaborative work between the Product Owner and also the development team. The next attribute to consider when ordering the Product Backlog is risks. When we're talking about risks its risk of failure because the product is delivered too late. One known example here is Windows Phone. Another risk is if customers don't embrace our product even though we deliver the product early. One known example here is Friendster. Ideally we want to deliver the product at the right time. Not too early, not too late. Because both have risks. Ideally risk is quantified to numbers or dollar value. Awesome Product Owners quantify risk and map it into cost of delay. On top order of the Product Backlog ideally are items that have risks that are worth fighting for. We should leave silly risk at the bottom order of the Product Backlog.
The next attribute to consider when ordering the Product Backlog is perceived value. We call it perceived value because the real value can only be generated after the product is released and being used by the customers. So until the product is released and in the hand of customers we only have perceived value. To avoid decision making based on political power ideally perceived value is quantified in numbers to help Product Owners to order the Product Backlog. Even better if we can provide a spreadsheet on how we came up with the perceived value to the Product Owner. Ideally on the top order are the high perceived value items and on the bottom order are the low perceived value items. Ideally you have more high perceived value items than low perceived value items on the top order of the Product Backlog. Amount of learnings is another attribute that the Product Owner must consider when ordering the Product Backlog because it's related to risk and also perceived value. Product Owners want to create small experiments that will result in learning to avoid the risk of losing tons of investments. Many awesome Product Owners will also argue that value is unknown and fuzzy, so the only way to identify where value is located is by creating small experiments. Ideally learnings is also quantified to numbers so Product Owners can create delivery strategy easily. Ideally on the top order of the Product Backlog are items that will give the organisation many learnings while on the bottom order are the items that do not give the organisation much learnings. So if we consolidate all of these Product Backlog item attributes and create a Venn diagram between the Product Backlog item size, perceived value, risk and learning. Ideally the ones on the top order of the Product Backlog are the one shown on this orange area.
Besides the attributes on the Product Backlog item, the Product Owner decision on the order of the Product Backlog may also be influenced by the customer and the consumer expectations, market conditions and the competition landscape. The Product Owner should also be open minded and considers feedback from the development team. If the current product is in a bad state the Product Owner will put defects and technical debt on the top border of the Product Backlog. [Music] Product Owner is trusted to be able to do an awesome job to optimize the value of the product. The order of the Product Backlog will reflect the value that the organisation will obtain. No one in the organisation can override Product Owner's decision regarding the order of the Product Backlog, even those with highest political power. Otherwise the Product Owner cannot really take ownership of the product and the product owner is not more than just a proxy. So that is all from me today folks I hope you found that this video helpful. Especially if you are an aspiring Product Owner. Hopefully today's video helps you create strategies to optimize the value of your product.