<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>estimation on Agile Software Development</title>
    <link>https://agilesoftdev.com/tags/estimation/</link>
    <description>Recent content in estimation on Agile Software Development</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 02 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://agilesoftdev.com/tags/estimation/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Planning Poker Works, But Not for the Reason Most Teams Think</title>
      <link>https://agilesoftdev.com/planning-poker-works-but-not-for-the-reason-most-teams-think/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/planning-poker-works-but-not-for-the-reason-most-teams-think/</guid>
      <description>Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one&amp;rsquo;s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.</description>
    </item>
    
    <item>
      <title>The #NoEstimates Argument Deserves to Be Taken Seriously</title>
      <link>https://agilesoftdev.com/the-#noestimates-argument-deserves-to-be-taken-seriously/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/the-#noestimates-argument-deserves-to-be-taken-seriously/</guid>
      <description>The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.</description>
    </item>
    
    <item>
      <title>Velocity Is a Planning Tool, Not a Performance Metric</title>
      <link>https://agilesoftdev.com/velocity-is-a-planning-tool-not-a-performance-metric/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/velocity-is-a-planning-tool-not-a-performance-metric/</guid>
      <description>Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team&amp;rsquo;s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.</description>
    </item>
    
  </channel>
</rss>
