<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>user stories on Agile Software Development</title>
    <link>https://agilesoftdev.com/tags/user-stories/</link>
    <description>Recent content in user stories 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/user-stories/index.xml" rel="self" type="application/rss+xml" />
    <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>User Stories Are a Conversation Starter, Not a Requirements Document</title>
      <link>https://agilesoftdev.com/user-stories-are-a-conversation-starter-not-a-requirements-document/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/user-stories-are-a-conversation-starter-not-a-requirements-document/</guid>
      <description>The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.</description>
    </item>
    
  </channel>
</rss>
