5 Common Myths About The Scrum Product Backlog

this is the product backlog well it's one form of a product backlog I still like using a physical index card like this as a tool for describing and visualizing the product backlog now if you prefer using electronic tools that's fine as long as the product backlog is always made transparent to everyone in your organization everyone the reason why I want to talk about the product backl in today's video is because it is one of the elements in scrum that can get easily misunderstood among scrum practitioners and quite often this misunderstanding can lead to Value delivery ineffectiveness and because of that reason folks in today's video we are going to bust five mths related to the product backlog so I suggest buckle up because I will be back right after this

one the first misconception is that only the product owner who is responsible to refine or add more details onto each product backlog items that's how I discovered many scrum teams expect their product owner to be their personal secretary to detail every single item in the product backlog for them as described in scrum guide the product owner is accountable for Effective product backlog management but the product owner can delegate the responsibility in adding more details onto the product backlock items to the other scrum team members Now take notes how the scrum guide used the word accountable and respond responsible differently there another misconception in relation to this misconception is the developers in the scrum team are only the software Engineers now I have already made a video about who the developers in the scrum team are if you haven't watched that video go check out that video on this channel if you still have the perception that the developers in the scrum team are only limited to the people who write software codes the developers in the scrum team may also include but not limited to the business analysts quality engineers solution architect technical writers ux designers Etc because they're part of the scrum team therefore they may also collaborate with the product owner to refine and add details onto the product backlog

items the second misconception is managing product backlog does not involve deleading items from the product backlog there are several factors why certain product backlog items need to be leaded it may be because of changes in the market or a change in the organization and the leadership structure which may result in a change in the company's long-term strategy the Sprint review is one of the opportunities to gain feedback from the stakeholders whether certain items in the product backlock need to be deleted now other than the Sprint review of course as a self-managing team the scrum team can communicate with the stakeholders and get feedback from them at any time during the Sprint regarding whether certain product backlog items need to be

deleted the third misconception about the product backlog is it only contains features that need to be developed by the developers I see this misconception a lot in product development engagement that involves third party suppliers as written on scrum guide the product backlog is an ordered list of what is needed to improve the product this may include but not limited to the system architecture that the developers need to put in place or even a list of experiments to validate any assumptions about certain functionalities that will be developed or even defects the scrum team needs to fix or even technical improvements to be implemented for paying any technical debts in the product let's described in scrum guide the product backlog is the single source of work undertaken by the scrum team hence is not only limited to features that the scrum team will

develop now let's move on to the fourth misconception because the product backlog does not only contain features that will be developed it does not need to be written in user story format every single time I have found that one of the reason why some people assume that the product backlog items always need to be written in user story format is because the tools they're using give them such a perception another format beside the user story format is the job story format which you can see on the screen right now another format which is my favorite format is the hypothesis format and I've already made a video about the hypothesis format check out the video on this channel if you want to learn more about how to write your product backlog items in hypothesis format as an alternative to the user story

format now we are on to the fifth and the last misconception related to the product backlog that I see quite often among scrum practitioners some people still have the perception that only the product owner who is allowed to add items to thect product backlog while the developers need to ask permission from the product owner whenever they want to add items into the product backlog now this is a misperception now even though the product owner is accountable for Effective product backlog management it doesn't mean only the product owner who is allowed to add or delete items from the product backlog because there may be architecture and Technical Improvement related items or research and experiments that the product owner may not have any expertise in but those activities need to be added by the scrum team into the product backlog not only the developers even the stakeholders can add items into the product backlog as long as the product owner is accountable for the value of the product that's why it is important for everyone in the organization to lift the scrum values and not make the product backlog as a political tool all right that is enough

myth busting today folks and by the way if people in your company want to learn how to use the product backlog to improve shed and understanding and collaboration within the company go check out a brand new course from scrum. org called the professional scrum product backlog management skills from this video I hope you already get the sense that managing the product backlog is the whole scrum team responsibility it's not only the product owner's job hence the target audience for this training is not limited to only the product owner in fact I suggest bringing your whole scrum team including the engineers designers analysts architects or even the end user to this training to level up understanding in your company I hope to see you in one of my sessions folks or else you can join any sessions facilitated by your friendly professional scrum trainer in your neighborhood all right folks if you have any questions just leave it in the comment section down below I will talk to you again in my next video have a great week bye-bye