<?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>estimating | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/estimating/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 20 Feb 2023 16:09:09 +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>estimating | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<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>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>Estimates or NoEstimates Workshop</title>
		<link>https://www.scrumexpert.com/videos/estimates-or-noestimates-workshop/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 11 Feb 2019 15:08:11 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[estimating]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=5556</guid>

					<description><![CDATA[The default use of an “estimate-driven” approach is pervasive in software development efforts. While estimates can be useful, it is worthwhile to scrutinize our use of estimates, and to seek better ways to manage the development of software when estimates are not appropriate. Let’s explore the purpose and use of estimates and consider possible alternatives. The default use of an “estimate-driven” approach is pervasive in software development efforts, and while estimates can be useful, it is worthwhile to scrutinize our use of estimates of cost, time, and effort, and to seek better ways to manage software development projects. We depend on estimates to make important decisions, and yet we’re often disappointed by the results. There are a number of things to explore and many questions to ask. For example, do we really need estimates for all the things we are currently using them? Are we getting a reasonable benefit from them? Is it possible to manage software development projects without these estimates, or at least with fewer estimates? Is there a way to prove that estimates are helping us make good decisions? Is it possible there are other ways to approach our work? In this workshop session we’ll participate in some interactive information gathering activities to see if we can gain a shared idea of our current understanding of the purpose and use of estimates. We’ll examine the nature of software development projects, and see if we can work together to come up with some ideas about alternatives to using <a class="mh-excerpt-more" href="https://www.scrumexpert.com/videos/estimates-or-noestimates-workshop/" title="Estimates or NoEstimates Workshop">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Story Points Explained</title>
		<link>https://www.scrumexpert.com/knowledge/story-points-explained/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 12 Sep 2016 15:50:00 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3688</guid>

					<description><![CDATA[Metrics are an important part of Agile project management approaches like Scrum. One of the most used measures to estimate the amount of work are the story points. In this small article, Pedro Gustavo Torres explains what they are, why you need them and how to use them. Pedro Gustavo Torres provides many definitions of story points. One of them is &#8220;a unitless measure of magnitude for work yet to be done, based on relative sizing.&#8221; He explains also why you should use story points based on the difference between accuracy and precision. He wrote &#8220;Accuracy and precision are not the same thing. Precision is a lot more expensive. Precision is always desired, but accuracy creates more value. However, story points provide sufficient accuracy when working in nondeterministic systems.&#8221; It is very difficult to create a precise time estimate. Story points provide an estimate that is accurate enough to define the effort that should be included in Scrum sprints. With historical data, the team can assess the relationship between time and points. However, story points cannot be related to a specific duration, but rather with a duration interval. Read the complete blog post on https://www.scrumalliance.org/community/articles/2016/february/story-points-explained-the-what-why-and-how]]></description>
		
		
		
			</item>
		<item>
		<title>Estimates or #NoEstimates?</title>
		<link>https://www.scrumexpert.com/videos/estimates-or-noestimates/</link>
					<comments>https://www.scrumexpert.com/videos/estimates-or-noestimates/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 09 Dec 2015 17:40:03 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[estimating]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=2996</guid>

					<description><![CDATA[There&#8217;s a debate raging in the Agile world around the #NoEstimate concept: should we estimate, or not? Lost in the noise are more important questions: When should we estimate, and why? When should we not estimate, and why not? As with so many Agile questions, the answer to &#8220;should we estimate?&#8221; isn&#8217;t a clear-cut &#8220;yes&#8221; or &#8220;no.&#8221; Instead, the answer depends on what your team is capable of, what your organization needs, and how to best balance the two. This presentation takes a deep look at how estimates work, why they work, and when and why to discard them. Along the way, you will encounter surprising insights about the nature of Agile development and the teams that use it. Video producer: http://oredev.org/]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/estimates-or-noestimates/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Using Budget Instead of Estimates in Agile</title>
		<link>https://www.scrumexpert.com/knowledge/using-budget-instead-of-estimates-in-agile/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 08 Sep 2015 13:58:10 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=2747</guid>

					<description><![CDATA[Budget-based project management is an alternative to classic estimates that has some following in the Agile community. In their book &#8220;Fifty Quick Ideas to Improve your User Stories&#8221;, Gojko Adzic and David Evans, discusses how using a budget instead of estimates can help to deliver better projects. Detailed estimation works against the whole idea of flexible scope, but many companies we work with fall into a common trap when they insist on work duration estimates. ‘We are terrified of uncertainty – we would rather be wrong than uncertain,’ said Dan North at Oredev in 2011. A nice precise number feels good, it feels as if someone is in control. The premise of this process is deeply flawed, because all the estimates come with a margin of error that is rarely considered. There are several popular error reduction techniques, such as estimating with intervals of confidence and estimating based on statistical averages, but in many situations this is actually not the right problem to solve. Long-term estimates give the wrong impression of precision and promote long-term commitment on scope, which eliminates the biggest benefit businesses can get from agile delivery – adaptive planning. Instead of estimating, try to start with a budget for a bigger piece of work, in terms of both operational costs and time. This budget can then become a design constraint for the delivery team, similar to scalability or performance. Essentially, rather than asking ‘how long will it take?’, ask ‘when do you need this by?’ and ‘how <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/using-budget-instead-of-estimates-in-agile/" title="Using Budget Instead of Estimates in Agile">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Retrospectives for Story Points</title>
		<link>https://www.scrumexpert.com/knowledge/retrospectives-for-story-points/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 22 Jul 2014 15:32:49 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<category><![CDATA[retrospective]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=2069</guid>

					<description><![CDATA[At the end of each sprint, the Scrum team take some time to think about what could be improved in its Agile process. In this blog post, Natalie Warnert discusses how you could also use the retrospective meeting to look at story sizes after the sprint and determine if they were correctly sized as far as story points are concerned. As Natalie Warnert explains it: &#8220;This is not meant to point out shortcomings or blame when estimates are “wrong”. It’s simply to figure out if the team is all on the same page when determining amounts of effort and identifying discrepancies that hinder our estimating and therefore predictability or lack thereof.&#8221; The blog post explains how to structure such a retrospective meeting for story points which focuses on checking if the effort for stories of same sized point values is actually similar. You also analyse of the sizing was performed. The conclusion of Natalie Warnert is that &#8220;Any team can improve their sizing, especially if there is a lot of carry over in a certain sprint. This can also identify how the POs, team and ScrumMasters can help to get more information to get a better defined story that is more straightforward to estimate.&#8221; Read the complete article on http://nataliewarnert.com/story-point-comparison-retro/]]></description>
		
		
		
			</item>
		<item>
		<title>Estimation with Story Points in Scrum</title>
		<link>https://www.scrumexpert.com/videos/estimation-with-story-points-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 01 May 2013 14:57:15 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1488</guid>

					<description><![CDATA[Klaus Bucka-Lassen discusses the estimation with story points in Scrum. Story points are a different way to estimate features in Scrum. Story points are a measurement of a feature’s size relative to other features and not a measure of the time needed to complete a feature. [youtube igwvE6NaWak] Video Producer: http://gotocon.com/ Further reading on Agile estimation * Story Points: Why are they better than hours? * Why I Don’t Use Story Points for Sprint Planning * Transitioning From Time-Based to Relative Estimation * Stop Using Story Points * Relative Estimation Communication]]></description>
		
		
		
			</item>
		<item>
		<title>Simple Scrum Sprint Estimation Tool</title>
		<link>https://www.scrumexpert.com/knowledge/simple-scrum-sprint-estimation-tool/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 12 Mar 2013 18:15:53 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1437</guid>

					<description><![CDATA[Whether you follow a Agile framework like Scrum with its planning poker or a traditional project management approach, the estimation activity is always difficult to perform productively and consistently on the long term. In this article, Kirill Klimov shares a simple and lightweight estimation technique that should make the sizing process easier for a Scrum team. Story point is a relative sizing metric, which means that you always compare stories between them. This often works well at the very beginning the project, but when you estimate new stories, it becomes much difficult because the calibration of one story point is forgotten. Kirill Klimov suggests to create an &#8220;estimation net&#8221;, which is a visual table with one row for each estimation size you use. Having visual references during the sizing process helps the team, because there are real examples within each size and people can compare new stories to these examples. Read the complete article on http://www.scrumalliance.org/articles/481-the-estimation-net]]></description>
		
		
		
			</item>
		<item>
		<title>Self-Organization and Estimation in Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/self-organization-and-estimation-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 06 Feb 2013 13:44:24 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[self organized team]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1387</guid>

					<description><![CDATA[In Scrum the estimation effort and accuracy depend on the team. In this article, Jingjie Wang discusses the situation where the Scrum team tends to underestimate its capacity to deliver so to be sure that the product owner and the scrummaster are always happy at the end of each sprint because everything promised is deliver. But in Scrum the productivity is as important as the production of the team and this is an issue that must be addressed. Jingjie Wang proposes two tools that can help to monitor the productivity of the team: * Using story points rather than hours or days to estimate * Recording and reviewing the velocity of each sprint Jingjie Wang explains that improvement should not only come from monitoring productivity, but that it is also the job of the ScrumMaster to keep the team inspired and more aggressive on its commitment. In his case, he experiment by reducing the span of a Sprint from 15 days into 8 days, without decreasing the scope. All committed tasks were finished without any compromise in quality.]]></description>
		
		
		
			</item>
	</channel>
</rss>
