<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>requirements on Agile Software Development</title>
    <link>https://agilesoftdev.com/tags/requirements/</link>
    <description>Recent content in requirements 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/requirements/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Requirements Writing Is Now a Core Engineering Skill</title>
      <link>https://agilesoftdev.com/requirements-writing-is-now-a-core-engineering-skill/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/requirements-writing-is-now-a-core-engineering-skill/</guid>
      <description>For most of software&amp;rsquo;s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.</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>
