<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>product backlog | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/backlog/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 13 Jul 2026 23:44:46 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	

<image>
	<url>https://www.scrumexpert.com/wp-content/uploads/favicon.png</url>
	<title>product backlog | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Prioritize What Truly Matters in Backlog to Focus on Results</title>
		<link>https://www.scrumexpert.com/videos/prioritize-what-truly-matters-in-backlog-to-focus-on-results/</link>
					<comments>https://www.scrumexpert.com/videos/prioritize-what-truly-matters-in-backlog-to-focus-on-results/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 24 Jun 2026 14:19:12 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[product backlog]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8787</guid>

					<description><![CDATA[This presentation explains how an organization moved from 17 component backlogs to one shared, results-focused product backlog—and what that changed for delivery speed and alignment. The presenters explain how “autonomous” component teams optimized for local work, not customer value, creating high WIP, heavy dependencies, and long lead times. By restructuring into cross-functional feature teams, running one shared cadence, and prioritizing work for the whole product, they dramatically improved flow. The talk also covers their next step: shifting from output (features) to outcomes (user behavior change) using continuous discovery. The key outcomes from the changes in product backlog prioritization approach were: Time-to-market reduced from ~7 months to ~40 days Up to 80% shorter delivery time (≈5× faster) Same people—better structure, clearer priorities Video producer: https://less.works/]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/prioritize-what-truly-matters-in-backlog-to-focus-on-results/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>The Cone of Uncertainty in Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/the-cone-of-uncertainty/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 30 Mar 2026 12:00:53 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=815</guid>

					<description><![CDATA[Uncertainty in the Product Backlog is a big risk for the schedule of a Scrum project. How clever your estimations might be, Agile has to consider them using the notion of &#8220;cone of uncertainty&#8221;. The problem when trying to plan in Scrum is that the full scope of the release in Agile software development can be quite hard to estimate. This is due to the fact that the requirements are intentionally not well-know early on in the process. Confounding this problem is that frequently the release date is a hard deadline. This means that an Agile team must perform an unknown amount of work in a fixed amount of time. The &#8220;Cone of Uncertainty&#8221; describes the reduction of the uncertainty about scope after each Scrum sprint. It is only at the end of an Agile project that you eliminate the uncertainty and know the exact amount of scope is known. In anticipation of scope problems in project management, the software development schedule should be aligned to address the highest priority feature sets and features in early iterations. You defer lower priority feature sets and features to later iterations. To reduce the Cone of Uncertainty and the risks around missing a release deadline further, the requirements lead (product owner) and the Scrum team should actively defer low priority features from all feature sets to later sprints. These are the key considerations and decision points for reducing the Cone of Uncertainty in Agile: Primary goal: reduce dangerous uncertainty (feasibility, integrations, regulatory risk) <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/the-cone-of-uncertainty/" title="The Cone of Uncertainty in Scrum">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Why Estimating is Not Part of Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/why-estimating-is-not-part-of-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 24 Aug 2022 14:08:05 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[product backlog]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7173</guid>

					<description><![CDATA[If estimating is a core activity of traditional project management, Zuzana “Zuzi” Šochová explains to us in this article that it is not used by advanced Agile and Scrum teams. Instead, the focus should be on being more reactive to changes and responsive to feedback. We are realizing that Agile is not about plans, but planning as a continuous activity. Author: Zuzana “Zuzi” Šochová, http://sochova.cz/ There is almost no class where no one would ask me about estimations. So why estimations are not part of Scrum? Let’s start with a bit of context. The whole idea of agile estimation comes from Extreme Programming and the early days of agile where tools like Story points, Velocity, Planning Poker, Burndown, T-shirt sizing, used to be very popular. However, if you look at current state of the art of Agile and Scrum teams, they are not using those techniques very often anymore. Estimations were always core part of any project management, where we believed we know what needs to be done, so the whole problem is not about WHAT but HOW FAST. Therefore, tracking the velocity, showing the burndown and estimating is very useful in such predictable environments where there is only little unknown. So when people shift to their first agile project, they very often still have the same mindset – we know what needs to be done so let’s create a backlog, estimate individual backlog items, and track how fast we are delivering it. That’s the world where estimates, Story Points, Burndown <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/why-estimating-is-not-part-of-scrum/" title="Why Estimating is Not Part of Scrum">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>5 Tips to Improve Product Backlog Refinement</title>
		<link>https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/</link>
					<comments>https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 07 Mar 2022 16:09:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6953</guid>

					<description><![CDATA[The Product Backlog Refinement (PBR) activity is one that many new Scrum teams struggle with. Insufficient PBR often results in long sprint planning meetings and incomplete backlog items at the end of the sprint. This article provides some tips on how to improve backlog refinement, which in the past was called backlog grooming. Author: Anthony Mersino, Vitality Chicago, https://vitalitychicago.com/ Backlog refinement is the process of discussing, breaking down, gathering details, and estimating backlog item. The focus is on what is needed and why, rather than on how to solve the business need. Backlog refinement is done in the current sprint, for future backlog items, not for those backlog items that are in the current sprint. Participants in the backlog refinement process include the entire development team, appropriate subject matter experts (SMEs), the product owner or requestor for the item, and possibly the Scrum Master. Others may attend but those are the main actors. Why Product Backlog Refinement is Important Product Backlog Refinement or PBR is not only important, but it is also critical for Scrum Teams. The refinement, or grooming as it used to be called, helps align the team on the details of the backlog item. It leverages the insights from all team members to add necessary details to the backlog item. And it should involve a discussion with the product owner, customer or requestor so that the team can gather all the details about the requested item and why it is needed. Good backlog refinement processes will reduce <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/" title="5 Tips to Improve Product Backlog Refinement">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Build a Powerful Roadmap</title>
		<link>https://www.scrumexpert.com/videos/build-a-powerful-roadmap/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 15 Dec 2020 14:52:01 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[delivering value]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6486</guid>

					<description><![CDATA[This video will provide you with practical techniques on how to build a powerful roadmap for your product or service, one that allows any Agile organization to get valuable feedback from their customers and deliver business value. Any organization&#8217;s ability to focus on what matters most to their customers is directly related to their ability to get valuable feedback from them. While more and more organizations embrace agile practices during the development of their services, they often lack in how they collect feedback and therefore don&#8217;t get the benefits they are after. After all, what is the upside to investing in being able to pivot, if there is no information available to guide the direction of that pivot? The fact that many roadmaps leave little room for flexibility significantly contributes to this and building powerful roadmaps is a really hard task. How does one get feedback about a house without building it completely? How does one give feedback about a car without being able to drive it around the city for a couple of hours? Video producer: https://agileindia.org]]></description>
		
		
		
			</item>
		<item>
		<title>Why Splitting Unfinished Product Backlog Items is a Bad Idea</title>
		<link>https://www.scrumexpert.com/knowledge/why-splitting-unfinished-product-backlog-items-is-a-bad-idea/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 16 May 2017 08:33:57 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4413</guid>

					<description><![CDATA[In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don&#8217;t have a &#8220;done&#8221; status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items. Author: Daniel Zacharias, Hexacta, http://www.hexacta.com/ In the Agile world of Scrum, there are two types of product backlog items (PBIs) at the end of a sprint: those that are done – that comply with the Definition of Done or DoD – and those that are not. If we want to be faithful to the methodology, those unfinished PBIs, regardless of their degree of progress, should be returned to the product backlog. (see also: 5 keys you can’t skip on your agile process). Once the unfinished PBI is put back into the product backlog, the product owner must prioritize it again and include it (or not) into the next sprint to finish it. When re-assigned back to a sprint, the amount of story points assigned to this PBI should not change, since the effort to implement it, as a whole, remains the same. However, many of us who work with Scrum have lived through the situation where a sprint has finished and one of its PBIs is incomplete. It’s tempting to split it into two and leave <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/why-splitting-unfinished-product-backlog-items-is-a-bad-idea/" title="Why Splitting Unfinished Product Backlog Items is a Bad Idea">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Storytelling: the Big Picture for Agile Efforts</title>
		<link>https://www.scrumexpert.com/videos/storytelling-the-big-picture-for-agile-efforts/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 19 Apr 2017 14:32:19 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4339</guid>

					<description><![CDATA[Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos. Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed product backlogs. The onion metaphor that is popularly used in agile planning can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including asking, observing, showing and hybrids. Using the onion metaphor, techniques for developing and splitting user stories are the second layer of the onion. However, before getting to the center of the backlog evolution onion, we need to understand the big picture. Video producer: http://oredev.org/]]></description>
		
		
		
			</item>
		<item>
		<title>Agile Requirements: a Definition of Ready Checklist</title>
		<link>https://www.scrumexpert.com/knowledge/agile-requirements-a-definition-of-ready-checklist/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 01 Nov 2016 15:30:36 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[requirements]]></category>
		<category><![CDATA[user stories]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3810</guid>

					<description><![CDATA[We all know the &#8220;Definition of Done&#8221; used in Scrum for items that should be potentially shippable to the customer at the end of the sprint. In his book Essential Scrum, Kenneth Rubin discusses the &#8220;Definition of Ready&#8221; that applies to product backlog items that should be ready to be developed before the start of the sprint. Grooming the product backlog should ensure that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently commit and complete them by the end of a sprint. Some Scrum teams formalize this idea by establishing a definition of ready. You can think of the definition of ready and the definition of done as two states of product backlog items during a sprint cycle. Both the definition of done and the definition of ready are checklists of the work that must be completed before a product backlog item can be considered to be in the respective state. An example of a definition-of-ready checklist for product backlog items is given below. Definition of Ready * Business value is clearly articulated. * Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the product backlog item (PBI). * Dependencies are identified and no external dependencies would block the PBI from being completed. * Team is staffed appropriately to complete the PBI. * The PBI is estimated and small enough to comfortably be completed <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/agile-requirements-a-definition-of-ready-checklist/" title="Agile Requirements: a Definition of Ready Checklist">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Product Backlog Refinement Checklist</title>
		<link>https://www.scrumexpert.com/knowledge/product-backlog-refinement-checklist/</link>
					<comments>https://www.scrumexpert.com/knowledge/product-backlog-refinement-checklist/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 22 Aug 2016 14:22:53 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3638</guid>

					<description><![CDATA[Product backlog refinement (or grooming) is an important activity in Scrum projects where user stories are prioritizes, right-sized and estimated. In his book &#8220;Agile Reflections&#8221;, Robert Galen provides some hints about how to verify that that product backlog grooming has been done successfully and that the right requirements information is available for the next sprint. 1. Sprint planning is incredibly crisp, short and easy; usually taking 2 hours or less for a 2-week sprint. There are NO architectural or design discussions within the meeting—the relevant parts of these discussions having occurred earlier. 2. As a daily occurrence, team members are talking about epics and stories targeted for 2-3-4 sprints in the future. As a result, everyone is naturally aligning with the Product Owners’ vision. 3. The team easily contributes new stories to the backlog which represents non-feature based work; for example: testing artifacts, non-functional testing work, refactoring, automation development, performance tuning, research spikes, etc. Everyone views it as a shared responsibility. 4. The team has a feel for where the product is going long term and maps efforts, designs, theme suggestions, and trade-offs towards that vision. 5. Each sprint’s goal is easily derived from the backlog; i.e., there is a sense of thoughtful and meaningful story collections or themes that easily surface from within the backlog. From time to time, think of these as “packages” for customer delivery. 6. The Product Owner includes team feedback (bugs, refactoring, improvement, testing, etc.) in EVERY sprint &#8211; in some percentage of focus. They <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/product-backlog-refinement-checklist/" title="Product Backlog Refinement Checklist">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/product-backlog-refinement-checklist/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Facilitating Product Backlog Refinement</title>
		<link>https://www.scrumexpert.com/videos/facilitating-product-backlog-refinement/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 15 Aug 2016 18:33:45 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3623</guid>

					<description><![CDATA[It can be complicated to involve the whole team to facilitate product backlog refinement and take part in requirements discussions. I would like to suggest a structure of the PBR (product backlog refinement) meeting that will encourage everybody to speak up and share their ideas on functionality. This presentation explores what facilitation techniques to use for discussion, what prioritization and estimation models are applicable for business requirements, what documents and metrics can help us to make accurate planning and how to track the results of this meeting. https://vimeo.com/164063855 Video producer: http://aceconf.com/]]></description>
		
		
		
			</item>
	</channel>
</rss>
