<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>sprint planning on Agile Software Development</title>
    <link>https://agilesoftdev.com/tags/sprint-planning/</link>
    <description>Recent content in sprint planning 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/sprint-planning/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Backlog Refinement Is the Most Underrated Practice in Scrum</title>
      <link>https://agilesoftdev.com/backlog-refinement-is-the-most-underrated-practice-in-scrum/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/backlog-refinement-is-the-most-underrated-practice-in-scrum/</guid>
      <description>Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.</description>
    </item>
    
    <item>
      <title>Definition of Ready Is the Guardrail That Sprint Planning Needs</title>
      <link>https://agilesoftdev.com/definition-of-ready-is-the-guardrail-that-sprint-planning-needs/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/definition-of-ready-is-the-guardrail-that-sprint-planning-needs/</guid>
      <description>Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.</description>
    </item>
    
    <item>
      <title>Splitting User Stories Is a Skill Most Teams Develop Too Late</title>
      <link>https://agilesoftdev.com/splitting-user-stories-is-a-skill-most-teams-develop-too-late/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/splitting-user-stories-is-a-skill-most-teams-develop-too-late/</guid>
      <description>The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team&amp;rsquo;s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.</description>
    </item>
    
    <item>
      <title>The Sprint Goal Is the Most Skipped Part of Scrum</title>
      <link>https://agilesoftdev.com/the-sprint-goal-is-the-most-skipped-part-of-scrum/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/the-sprint-goal-is-the-most-skipped-part-of-scrum/</guid>
      <description>The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.</description>
    </item>
    
    <item>
      <title>What Sprint Planning Looks Like When Throughput Has Doubled</title>
      <link>https://agilesoftdev.com/what-sprint-planning-looks-like-when-throughput-has-doubled/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/what-sprint-planning-looks-like-when-throughput-has-doubled/</guid>
      <description>Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.</description>
    </item>
    
  </channel>
</rss>
