<?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>planning | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/planning/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 13 Jul 2026 23:45:29 +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>planning | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Open Source Planning Poker Tools</title>
		<link>https://www.scrumexpert.com/tools/open-source-planning-poker-tools/</link>
					<comments>https://www.scrumexpert.com/tools/open-source-planning-poker-tools/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 27 May 2026 10:00:29 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Tools]]></category>
		<category><![CDATA[Headline]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[planning poker]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6030</guid>

					<description><![CDATA[The first thing to say is that the term “Planning Poker®” is a registered trademark of Mountain Goat Software, the Mike Cohn company. This is why this agile planning practice could be sometimes names differently: scrum poker, agile poker, etc. This article presents a list of free and open source planning poker tools and plugins that are also directly available as online tools. Planning poker is originally a card game used by Scrum teams to estimate effort or relative size of user stories or features when during sprint planning. Team members estimates by playing numbered cards face-down to the table. Then the cards are revealed and the estimates are discussed. Discussion is the main interest of playing planning poker, because some developers will share why they vote differently from the consensus. This can be done with paper cards if the team is collocated, but in the case of a distributed Scrum team, you need to use a software to do it. Using a tool also makes it easier to record and remind previous planning estimations. There are many open source implementations of the Agile planning poker practice. I have decided to present only those who have also an online website or that are built as a plugin for another application like Slack, Jira, Trello, Discord or the Azure Boards. If a good tool is missing from this list, do not hesitate to contact us, and we will add it in a future update. Updates May 27 2026 Added: Card Estimator <a class="mh-excerpt-more" href="https://www.scrumexpert.com/tools/open-source-planning-poker-tools/" title="Open Source Planning Poker Tools">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/tools/open-source-planning-poker-tools/feed/</wfw:commentRss>
			<slash:comments>2</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>How to Approach Risk Management in Scrum Framework</title>
		<link>https://www.scrumexpert.com/knowledge/how-to-approach-risk-management-in-scrum-framework/</link>
					<comments>https://www.scrumexpert.com/knowledge/how-to-approach-risk-management-in-scrum-framework/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 20 Sep 2022 08:28:59 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[planning]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7216</guid>

					<description><![CDATA[With its iterative approach, the Scrum framework enables teams to minimize risk and manage risks confidently. Risk can creep into various elements when managing a project and prevent you from delivering a valuable project. But it takes much more than risk awareness to head off these risks. Author: Caroline Li You need a strategy to help you manage, accept, prioritize, or transfer these risks. Enterprise risk management provides a formal and deliberate process to deal with all types of threats. Dig in as we detail how to approach risk management in Scrum and how to do it properly. What is enterprise risk management Enterprise risk management is a top-down risk management strategy to identify, assess, and prepare for potential risks that may lead a business to incur losses. ERM uses a firm-wide approach to alleviate the risks that may impact your business objectives. Enterprise risk management uses a holistic approach to launch firm-wide surveillance. It helps uncover potential risks invisible to individual business branches. ERM facilitates communication between departments to minimize risks and identify unique opportunities. The holistic approach enables the top management to make informed decisions when determining the risks, they wish to manage actively. Successful ERM strategies help companies mitigate risks in core areas, such as financial, operational, compliance, legal, security, and strategic risks. A chief risk officer identifies, analyzes, and mitigates both internal and external risks when implementing an ERM. Why ERM is Important in Project Management Incorporating ERM into your scrum process is crucial in helping you establish <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/how-to-approach-risk-management-in-scrum-framework/" title="How to Approach Risk Management in Scrum Framework">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/how-to-approach-risk-management-in-scrum-framework/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</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>Scrum Planning Poker Estimation Scales</title>
		<link>https://www.scrumexpert.com/knowledge/scrum-planning-poker-estimation-scales/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 21 Feb 2022 10:17:31 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[planning poker]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6911</guid>

					<description><![CDATA[During the sprint planning meetings, the Scrum team plan the work to be performed during the next sprint. As the Scrum sprint is a time-boxed period, the delivery of software has to be calibrated to fit in it. Planning poker is a collaborative estimation technique used to achieve this goal. Planning Poker is a process defined (and registered) by Mike Cohn. During a planning poker session, upcoming features are discussed and refined by the product owner and the developers. Then, estimators select one card to represent the value of their estimate. All cards are revealed at the same time. The value of the scale can then be translated in story points, ideal days or other concept used by the teams to finalize the sprint planning. The usage of a scale instead of traditional man/days metric offers a simpler and stable measure of the backlog complexity, whether the effort required for each user story and the speed of its delivery (velocity) might vary during the evolution of the team in time. It is important to remember that, as many of the Agile software development practices, the main goal of a planning poker session is to create a discussion in the Scrum team and fulfill the objectives of interactions, collaboration and teamwork promoted by the Agile Manifesto values and principles. The situation is simple if everybody agrees on the complexity of a backlog item. Otherwise, people with smaller or larger estimates should share their reasons for thinking differently than their colleagues. Here <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/scrum-planning-poker-estimation-scales/" title="Scrum Planning Poker Estimation Scales">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Sprint Poker by Parabol – Agile Estimation for the Remote Age</title>
		<link>https://www.scrumexpert.com/tools/sprint-poker-by-parabol-agile-estimation-for-the-remote-age/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 22 Mar 2021 14:51:39 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Tools]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[planning poker]]></category>
		<category><![CDATA[retrospective]]></category>
		<category><![CDATA[white papers]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6594</guid>

					<description><![CDATA[Parabol is an agile meeting tool that helps remote teams run guided retrospective, check-in and Sprint Poker meetings. Parabol’s structured format and built-in templates make it easy for facilitators to run a great agile meeting – no matter if you&#8217;re a pro or just starting out. It’s free to use for up to two teams. Author: Gareth Davies, Parabol, https://www.parabol.co/ Agile estimation can be a pretty complex process at the best of times. But it becomes a lot more complicated when you’re a remote team. We know, because we spoke to agile teams all around the world about their remote estimation process. We heard our fair share of horror stories: Scrum masters copy/pasting stories from Jira to their planning poker tool. Team members juggling three or more windows. Facilitators frantically counting fingers on a video call, while struggling to keep discussions on point and efficient. We set out to fix that with Sprint Poker – a free Planning-Poker-style tool for agile teams. Here are 6 reasons we think you owe it to yourself to try Sprint Poker: 1. Fun and engaging meetings Nobody likes boring meetings. You don’t. Your team-mates definitely don’t. When meetings are boring, chances are you’re not getting a whole lot out of them. We designed Sprint Poker to keep everyone engaged and contributing. Here are a few of the ingredients we’ve included: 🃏 Interactive card deck: It wouldn’t be Planning Poker without a deck of cards, would it? Play around with a fun deck of cards to select your estimate. Every deck <a class="mh-excerpt-more" href="https://www.scrumexpert.com/tools/sprint-poker-by-parabol-agile-estimation-for-the-remote-age/" title="Sprint Poker by Parabol – Agile Estimation for the Remote Age">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>5 Minute Quick Scrum Guide &#8211; Should I Use Story Points Or Hours?</title>
		<link>https://www.scrumexpert.com/knowledge/5-minute-quick-scrum-guide-should-i-use-story-points-or-hours/</link>
					<comments>https://www.scrumexpert.com/knowledge/5-minute-quick-scrum-guide-should-i-use-story-points-or-hours/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 15 Mar 2021 14:33:20 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[white papers]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6586</guid>

					<description><![CDATA[There is plenty to fret about when you are running or on an agile team, but your measure of estimation should be one of them. In fact, despite what you may have heard from consultants or others, Scrum is not prescriptive about any particular estimation measure, let alone story points. Many practitioners support story points and it has been very in vogue for a while now, you should do whatever you and your team feels most comfortable with. Author: Jerry Lupo, CEO and founder of Scrumfast.com To be sure, all online agile tools such as Jira, Trello, Monday, ClickUp are indifferent when it comes to story points or time. At Scrumfast &#8211; a free project management tool for agile development &#8211; we take it so far as to just use the term “points”, so you don’t have to consider a more specific definition. Definition of Story Points While many practitioners laud the use of story points, there is no real consensus on what a story point even is. Derek Davidson of Scrum.org makes a good attempt when he says: “A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements.“ There is a couple of important take-homes from this description. First, it mentions that the measures are decided upon by “individual Scrum teams”. That means it is a measure that can’t be used across Scrum teams. Second, it notes that story points provide “relative estimates of effort” by the team, not the individual. Finally, there is <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/5-minute-quick-scrum-guide-should-i-use-story-points-or-hours/" title="5 Minute Quick Scrum Guide &#8211; Should I Use Story Points Or Hours?">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/5-minute-quick-scrum-guide-should-i-use-story-points-or-hours/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Applying Exception Management to Agile Teams</title>
		<link>https://www.scrumexpert.com/knowledge/applying-exception-management-to-agile-teams/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 11 May 2020 13:26:56 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[scrum team]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6304</guid>

					<description><![CDATA[The values contained in the Manifesto for Agile Software Development might be good for the Agile teams, but most of the senior management in organizations prefer having a defined solution, a detailed planning and a budget that should be respected. This article discusses how to make these two different approaches work together. Author: John Carter, TCGen, https://www.tcgen.com/ Your development teams may be Agile, but chances are that your Management team isn’t. Upper management lives in a world where there are known and limited budgets and where they are accountable for the quality of their investments. In a public company they have made commitments to financial markets to perform to spec and in a certain timeframe. We have piloted with several organizations a model that creates a bridge between Agile development teams and senior management. This bridge is built on exception management. Not Every Problem Has An Agile Solution Agile is a great way to get more features delivered, faster but not all problems have Agile as their solution. These larger problems are often external to the team. They have the potential for doing serious damage to an organization. Problems that require solutions outside Agile includes: Funding more than 2x initial allocation Quality so low, it will affect brand perceptions Dependencies that cause one or more teams to fail De-featuring so dramatic that it jeopardizes project justification Regulatory problems (legal, trade, safety, privacy) Creating an agreement between the team and management Our bridge between the Agile team and management resolves these <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/applying-exception-management-to-agile-teams/" title="Applying Exception Management to Agile Teams">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>A Coach’s Guide to Release Planning</title>
		<link>https://www.scrumexpert.com/knowledge/a-coachs-guide-to-release-planning/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 16 Apr 2018 14:50:11 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Books]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[coaching Agile]]></category>
		<category><![CDATA[planning]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=5050</guid>

					<description><![CDATA[A Coach’s Guide to Release Planning is part of the nice series proposed to Agile coaches by Samantha Laing and Karen Greaves. This book provides a complete plan to run a workshop where people can learn how to plan their release in an Agile way, a topic that should interest the whole Scrum team. As the rest of the series, this book uses the “Training from the BACK of the room (TFTBOTR)” approach that splits each sessions in four &#8220;C&#8221; parts: Connections, Concepts, Concrete Practice and Conclusion. On this basis, the book proposes chapters that deal with product planning, roadmap management or portfolio prioritization. It discusses also techniques like story mapping and release burnup. As with all the books of Samantha Laing and Karen Greaves, the material is well structured and easy to read. This download includes the 4C template, Working Agreement Cards, the full Training Plans and the Slide deck. From the developers to the product owner, all members of the Scrum team should be involved in planning and thus should read this book. The material will be also interesting for project and product managers that work in a context using traditional project management approaches. Reference: A Coach’s Guide to Release Planning, Samantha Laing and Karen Greaves, http://leanpub.com/ReleasePlanning Quotes Some people have a misconception that teams MUST deliver a certain velocity, and that if they do not they should work overtime. If that’s the feeling in the room, try spend some time helping them see how this might impact <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/a-coachs-guide-to-release-planning/" title="A Coach’s Guide to Release Planning">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Cost of Delay &#038; Better Prioritization</title>
		<link>https://www.scrumexpert.com/videos/cost-of-delay-better-prioritization/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 19 Feb 2018 14:26:24 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[planning]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4943</guid>

					<description><![CDATA[The Cost of Delay is a concept that combines an understanding of value with how that value leaks away over time. it allows to answer the question: &#8220;What would it cost us if this was delayed by 1 month?&#8221;. This presentation explores the Cost of Delay, what it is and how it helps in improving prioritization. You can use the Cost of Delay to surface assumptions and focus on what is valuable and urgent. The Cost of Delay helps you get more of what you want, faster. If you want to move on from prioritization by gut-feel, MoSCoW hell or HiPPO(highest-paid person&#8217;s opinion)-driven decisions, you need to understand Cost of Delay. It also help you making better decisions. Product development is full of trade-offs. What are our queues costing us? Use Cost of Delay for better decisions and enable distributed decision-making at all levels in your organization. If the system has little or no information about value and urgency it will optimise for other things – typically cost and dates, which tends to drive the wrong behaviors. Video producer: http://oredev.org/]]></description>
		
		
		
			</item>
	</channel>
</rss>
