<?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>requirements | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/requirements/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Thu, 01 Oct 2026 12:40:41 +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>requirements | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Building the Right Product vs Building the Product Right</title>
		<link>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Fri, 28 Aug 2026 20:47:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8834</guid>

					<description><![CDATA[In his book &#8220;Specification by Example &#8211; How successful teams deliver the right software&#8221;, Gojko Adzic had some interesting quotes about building the right product. &#8220;In the last decade, the software development community has strived to build software the “right” way, focusing on technical practices and ideas to ensure high-quality results. But building the product right and building the right product are two different things. We need to do both in order to succeed. To build the right product effectively, software development practices have to provide the following: * Assurance that all stakeholders and delivery team members understand what needs to be delivered in the same way. * Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps. * An objective means to measure when a piece of work is complete. * Documentation to facilitate change, in terms of both software features and team structure.&#8221; Source: &#8220;Specification by Example &#8211; How successful teams deliver the right software&#8221;, Gojko Adzic, Manning This idea of &#8220;building the right&#8221; product is also the center of the &#8220;Software Testing is Dead&#8221; presentation made by Alberto Savoia at the Google Test Automation Conference 2011.  I strongly agree that you cannot have a successful project without good requirements (which mean also good domain experts and product owners). We should however not forget that the right product would not be used if it is not working right. Keeping also the focus on building quality into the application is mandatory. You must do both, <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/" title="Building the Right Product vs Building the Product Right">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>The 3 S of User Stories: Simple; Single; Specific</title>
		<link>https://www.scrumexpert.com/videos/the-3-s-of-user-stories-simple-single-specific/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 30 Jul 2026 15:36:37 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[requirements]]></category>
		<category><![CDATA[user stories]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8822</guid>

					<description><![CDATA[User stories are the cornerstone of Agile requirements. Scrum teams use them to plan and deliver solutions that meet their users’ needs. Beyond just solution requirements, user stories focus on value delivery from the perspective of the user, describing the capabilities needed, as well as the benefits they would provide. However, user stories can be tricky to write by Agile teams in a way that they are understood by our stakeholders and the delivery team. We may believe that everyone knows what is expected to be delivered, but then find we are wrong. All too often, stories are not delivered because they are misunderstood, too big, not scoped correctly, or missing detail. This session will explore how to write effective user stories using the three “S” of User Stories : Simple; Single; Specific. These three simple guidelines can help us to assess our user stories to ensure they are sized appropriately and well understood, enabling continuous value delivery by the Scrum team. Video producer: https://agileindia.org]]></description>
		
		
		
			</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>How Software Testers Help with Requirements in Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/being-a-software-tester-in-scrum/</link>
					<comments>https://www.scrumexpert.com/knowledge/being-a-software-tester-in-scrum/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 10 Mar 2026 12:00:01 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[Agile testing]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1634</guid>

					<description><![CDATA[As many testers have, I struggled in my first year on a Scrum team. How do I write tests without a spec? How do I know when I am done with software testing when there is no test plan? This article shows the important contributions that software testers on Agile teams can make in the requirements gathering activities of feature and user stories creation. Author: Dave McNulla, https://dmcnulla.wordpress.com/ Agile is not a process. It&#8217;s a set of values that are intended to help people develop software more quickly with better quality. If we value people and how we work together over tools and processes, we can figure out a way to get the job done better. If we value working software over great documentation, then we have a better chance at delivering working software. If we work with the customer instead of creating a rigid contract, then the software will be more like what the customer can use. If we value making the right changes over following a plan, then we have a better chance of getting past what the plan failed to account. There are also 12 key principles to support these values. Even with those values, and with the somewhat specific principles, they leave the door wide open to how a team does agile. Scrum is a way to develop software that uses the agile values and principles with some guidelines to help. The saying &#8220;it is hard by the yard but a cinch by the inch&#8221; &#8211; <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/being-a-software-tester-in-scrum/" title="How Software Testers Help with Requirements in Scrum">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/being-a-software-tester-in-scrum/feed/</wfw:commentRss>
			<slash:comments>3</slash:comments>
		
		
			</item>
		<item>
		<title>Requirement Specification vs User Stories</title>
		<link>https://www.scrumexpert.com/videos/requirement-specification-vs-user-stories/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 09 Dec 2024 17:44:39 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[requirements]]></category>
		<category><![CDATA[user stories]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8168</guid>

					<description><![CDATA[This video explores what makes good requirements and how agile user stories help to improve the quality of requirements, whatever the nature of our software development. What are software requirements and how do they relate to the Scrum user stories? Is it requirement vs user story, or user story as requirement? An important part of agile software development is its user or customer focus. Our aim as software developers is to deliver outcomes that our users want or need. To do that it is vital to focus our work on the outcomes that matter to our users. Actually, this is true of any software development, agile or not. Requirements are often used to define the steps to deliver a solution, this is a big mistake. Deciding what our system needs to do is a difficult problem. Designing software well is a difficult problem too. We should avoid trying to solve these two difficult problems together in a single step, by conflating requirements with design. Video producer: https://gotocon.com/]]></description>
		
		
		
			</item>
		<item>
		<title>Integrating User Feedback into Agile Processes for Continuous Improvement</title>
		<link>https://www.scrumexpert.com/knowledge/integrating-user-feedback-into-agile-processes-for-continuous-improvement/</link>
					<comments>https://www.scrumexpert.com/knowledge/integrating-user-feedback-into-agile-processes-for-continuous-improvement/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 06 Nov 2024 17:35:32 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8129</guid>

					<description><![CDATA[Today&#8217;s fast-paced and user-driven market requires constant improvement efforts that utilize customer ratings and reviews as part of Agile processes to foster continuous development. Companies must quickly adapt to customer feedback in order to keep pace with rapidly shifting customer needs; early incorporation of user ratings into Agile cycles provides invaluable insight that help prioritize features, address pain points and refine product offerings, ultimately increasing both the customer experience as well as remaining competitive within this ever-evolving marketplace. Agile Is Vital to Responding to User Feedback Agile methodology places great emphasis on collaboration, flexibility, and responsiveness to change. With its iterative structure, Agile provides the ideal way to quickly incorporate user feedback quickly. One of the core principles of Agile is adapting quickly based on continual learning &#8211; something which customer ratings and reviews aid greatly with. This all aligns perfectly with Agile values of providing value early and often while adapting to real-world data analysis and increasing cross-functional team collaboration. By taking advantage of customer ratings and reviews, Agile teams can quickly identify what works and doesn&#8217;t in a product from a user&#8217;s point of view directly. With such knowledge at their disposal, agile teams can make more informed decisions during sprint planning, backlog prioritization, and release management; additionally, having immediate data-driven feedback accelerates learning cycles by testing hypotheses quickly, implementing fixes quickly, measuring customer satisfaction continuously &#8211; guaranteeing product growth aligns with actual user needs and expectations. Why Customer Feedback Is Essential to Agile Success Customer feedback is <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/integrating-user-feedback-into-agile-processes-for-continuous-improvement/" title="Integrating User Feedback into Agile Processes for Continuous Improvement">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/integrating-user-feedback-into-agile-processes-for-continuous-improvement/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>Four Levels of Agile Requirements</title>
		<link>https://www.scrumexpert.com/knowledge/four-levels-of-agile-requirements/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 14 Nov 2023 21:41:26 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7699</guid>

					<description><![CDATA[This article discusses the clarity of requirements for Agile software development and explains how you can use a four-step process for gathering them with the four levels of agile requirements. Author: Sally Elatta, Agile Transformation Don’t you just love the word ‘Requirements’? It’s just so clear isn’t it – NOT! Have you ever heard your business customer say ‘I’ve already given you my requirements’ and the team then says ‘We haven’t received clear or detailed requirements’? The other side to this is when the team tells the customer ‘You are giving us too much details, don’t tell us where the button goes on the screen, just tell us what you want’. No wonder we have so many requirements related issues on our projects! During one of my previous PMI webinars we talked about Agile Requirements – Breaking Down EPICs and Prioritizing. I will take a stab through this blog at summarizing the levels of Agile (and frankly non Agile) requirements and how you can use a four-step process for gathering them. First, let’s start with the picture below. The picture shows four levels of requirements, and also on the left is the four-step process for gathering requirements. Agile Requirements Levels Visioning: This is the initial step of gathering requirements. The goal is to help identify all the Themes and some features desired. This exercise begins to define the scope of what is expected. Brainstorming: The goal of this step is to identify all the features and stories desired. The key <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/four-levels-of-agile-requirements/" title="Four Levels of Agile Requirements">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Technical User Stories Don&#8217;t Work</title>
		<link>https://www.scrumexpert.com/videos/technical-user-stories-dont-work/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 10 Oct 2023 21:46:42 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[requirements]]></category>
		<category><![CDATA[user stories]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7666</guid>

					<description><![CDATA[How do you organize the technical parts of your Agile software development work? Do you create Technical Stories or Technical User Stories alongside your User Stories? If so, we think that you are probably storing up some problems. This presentation talks about what are technical stories, and the use of technical stories vs user stories and describes why technical stories don’t work as a useful means of talking about, and planning our work. In Agile software development how we plan, organize and prioritize our work has a big impact on its quality. This video explores why that is the case, and how to do a better job. Video producer: https://gotocon.com/]]></description>
		
		
		
			</item>
		<item>
		<title>Driving Stakeholders Engagement with User Stories</title>
		<link>https://www.scrumexpert.com/videos/driving-stakeholders-engagement-with-user-stories/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 31 May 2023 14:27:08 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[requirements]]></category>
		<category><![CDATA[user stories]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7534</guid>

					<description><![CDATA[The presenter designed this workshop during COVID times to engage stakeholders better by using User Stories more efficiently. The idea of the workshop is to help people move away from the notion that User Stories are merely a &#8220;As a .. I want .. so that&#8221; writing template. They can be a full-fledged way of engaging with every stakeholder involved during an Agile product&#8217;s lifecycle. The topics covered in this presentation about user stories include myth busters around user stories, 3 amigos, specs by examples, BDD, ATDD, Zero defect policies, etc. Video producer: https://agileindia.org]]></description>
		
		
		
			</item>
		<item>
		<title>Book Review: Discover to Deliver: Agile Product Planning and Analysis</title>
		<link>https://www.scrumexpert.com/knowledge/discover-to-deliver-agile-product-planning-and-analysis/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 27 Feb 2023 15:43:59 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Books]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7423</guid>

					<description><![CDATA[Discover to Deliver is a book written by Ellen Gottesdiener and Mary Gorman. It aims is to help you to deliver a product that will please your customer. To achieve this goal, the book proposes a toolbox of techniques that are taken from multiple disciplines, from business analysis to software testing or product delivery. These practices are grouped in an agile and lean approach to product discovery and delivery. The main concepts of the book are to discover options that provide values to the product, to examine the seven product dimensions, to create partnerships with stakeholders, to use three levels of planning and structured conversations. The book starts with a case study that explains how the book concepts can be implemented in practice. The concepts are then presented in a more structured fashion. The book is well written, with a very “lean” style in the conceptual sections that allows you to grasp quickly its content. It also has a “timeline” on the top of every page that will give the “position” of the current content in the global flow of the book. I will naturally recommend this book to every product or project manager involved in the creation and delivery of software (and other) solutions, but other members of software development teams will find valuable content in this book. Its well-structured content makes it a good reference when you want to get guidance on a specific project activity. Reference: Discover to Deliver – Agile Product Planning and Analysis, Ellen Gottesdiener <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/discover-to-deliver-agile-product-planning-and-analysis/" title="Book Review: Discover to Deliver: Agile Product Planning and Analysis">[...]</a>]]></description>
		
		
		
			</item>
	</channel>
</rss>
