<?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 poker | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/planning-poker/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 poker | 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>On Story Points</title>
		<link>https://www.scrumexpert.com/knowledge/on-story-points/</link>
					<comments>https://www.scrumexpert.com/knowledge/on-story-points/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 01 Nov 2022 17:01:25 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[planning poker]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7259</guid>

					<description><![CDATA[User stories and story points are often used as a technique to define requirements and estimate work by Scrum teams. This article explains why it is not a good practice to use story points as an estimation tool with planning poker. Author: Rob Moffat, https://riskfirst.org/ In Scrum, the idea of a sprint is well named:  as a team, you are trying to complete work on a whole bunch of work items (stories) before a deadline. In a previous article in this series, Fixing Scrum we took against the idea of fixed time-boxes generally, because they introduce more problems than they solve:  as we’ve seen in multiple articles, estimating is hard, trying to use it as a solution to anything is misguided.  So you should only estimate when you absolutely need to. Nevertheless, knowing how long things will take is really the whole purpose of this track on Estimating, and sometimes unavoidable deadlines make it necessary. In Scrum, the Estimation process is based on the concept of story points, so that will be the focus here, although essentially this discussion is relevant to anyone estimating software development. In this article we will critique story points as an estimation tool.  First, we will break it down to see how it works (the diagram above will guide us) then we’ll offer some ideas for improving it. Inputs At a basic level, to calculate the number of story points for an item of work, you need the following inputs: A Story:  you’re going to <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/on-story-points/" title="On Story Points">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/on-story-points/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</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 Aspects of Scrum You Cannot Skip</title>
		<link>https://www.scrumexpert.com/knowledge/5-aspects-of-scrum-you-cannot-skip/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 22 Aug 2017 14:21:45 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[adoption]]></category>
		<category><![CDATA[planning poker]]></category>
		<category><![CDATA[retrospective]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4549</guid>

					<description><![CDATA[Some software development teams try to adopt Scrum, but they don&#8217;t achieve the full benefits of this approach. This might be due to the fact that the teams customize Scrum in a way that is inappropriate. In this article, Pablo Pecora suggests five aspects of Scrum, like the planning poker, that you cannot skip if you want to get the benefits of Agile. Author: Pablo Pecora, Hexacta, http://www.hexacta.com/ Are you really doing Scrum? Many teams in the software development industry might be wondering why Scrum doesn’t work for their projects. These are some key factors that any Scrum team can‘t avoid if they want to succeed. Even though many software development companies say they work with Agile methodologies .- Scrum in particular &#8211; some teams ask to themselves “Why Scrum doesn’t work for my team?”. Our question is: &#8220;Are they really doing Scrum?&#8221; In a methodology that has few principles and rules, failing to follow just a handful of them means that you are not complying with a big part of the whole Scrum framework. That will obviously carry some penalties in the result you get. The widely discussed benefits of Agile product development are sometimes overshadowed by some practices that have a negative effect when it comes to realizing Scrum’s full potential. Usually called “ScrumButs”, these bad practices are the excuses or fake shortcuts for not complying with the proposed methodology. The truth is that many teams think that they are using Scrum, but they are really skipping many <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/5-aspects-of-scrum-you-cannot-skip/" title="5 Aspects of Scrum You Cannot Skip">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Agile Project Wall Estimation</title>
		<link>https://www.scrumexpert.com/knowledge/agile-project-wall-estimation/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 30 Oct 2012 13:42:53 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[planning poker]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1269</guid>

					<description><![CDATA[In this article, Mitch Lacey discusses the difficulty faced when trying to provide estimates for software development project. The beginning of a software project is the time when you are the least certain about the final scope project, but it is also when you are asked to deliver precise estimates. Agile tries to move from uncertainty to certainty in as quickly as possible. The article presents two agile estimation techniques: planning poker and wall estimation. Planning poker is a good tool for estimating user stories, but it takes too much time to estimate hundreds of stories with this technique. Wall estimation allows stakeholders to prioritize a large group of stories without being trapped in discussions to decide if a particular story is slightly more important than another. Once the stories are grouped by size, customers and stakeholders can be involved to prioritize them. At the end of the sessions, your wall should break down roughly into four quadrants. The stories in the top left are high priority and small so they will end up in the top of the product backlog. The stories in the top right are high priority but are also large. These stories should be broken down soon so they can be brought into upcoming sprints. The lower left quadrant is made up of small stories that are lower in priority. They will likely fall to the bottom of the backlog. The lower right quadrant is filled with large stories that are also lower in priority. These <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/agile-project-wall-estimation/" title="Agile Project Wall Estimation">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Using Large Number in Planning Poker</title>
		<link>https://www.scrumexpert.com/knowledge/using-large-number-in-planning-poker/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 30 Nov 2011 06:31:25 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[planning poker]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=824</guid>

					<description><![CDATA[Mike Cohn wrote an interesting post where he discusses he allows or even encourages to estimate with story points as large as 20, 40, and 100. He explains that they are useful when you need first and not necessarily precise estimate of the general size of a new project being considered. His post generates an interesting discussion about the necessity to break requirements in smaller pieces, the difference between estimating and committing, playing Planning Poker during sprint planning or educating the stakeholders.]]></description>
		
		
		
			</item>
	</channel>
</rss>
