<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>userstoryantipatterns &amp;mdash; Steve Tooke</title>
    <link>https://tooky.uk/tag:userstoryantipatterns</link>
    <description>Thoughts and things</description>
    <pubDate>Wed, 15 Apr 2026 22:59:12 +0000</pubDate>
    <image>
      <url>https://i.snap.as/2kdixQrh.ico</url>
      <title>userstoryantipatterns &amp;mdash; Steve Tooke</title>
      <link>https://tooky.uk/tag:userstoryantipatterns</link>
    </image>
    <item>
      <title>Missing Hero</title>
      <link>https://tooky.uk/missing-hero?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[UserStoryAntiPatterns&#xA;&#xA;Problem&#xA;&#xA;The team are asked to define the User Stories for an upcoming initiative.&#xA;&#xA;Context&#xA;&#xA;The team / organisation are undergoing an Agile transformation&#xA;&#xA;Forces&#xA;&#xA;There is an expectation that the User Story template be followed&#xA;The team believe they have already have lots of customer knowledge&#xA;Product Owner has a strong engineering background&#xA;&#xA;Supposed Solution&#xA;&#xA;Create the stories based on the teams internal knowledge of the market and customer. Ensure that the User Story template is adhered to by just using &#34; The User&#34; where ever it asks for who. When there is a requirement that is internal facing, use an internal stakeholder. e.g. &#34;The Developers&#34; for uprgading dependencies, or &#34;The Product Owner&#34; for internal reports and analytics.&#xA;&#xA;Resulting Context&#xA;&#xA;User Stories become a list of features and tasks that just need to be executed.&#xA;There isn&#39;t scope to discuss alternative solutions because their isn&#39;t a shared understanding of exactly who needs the solution.&#xA;The product ends up with too many features that aren&#39;t used or difficult to use&#xA;&#xA;Alternate Solution&#xA;&#xA;Build a clear picture of the different User and Stakeholder personas.&#xA;Focus on those Personas, the problems they have, and what solving those problems will do for them&#xA;Bring the team together to create shared understanding and discuss options to solve those problems&#xA;&#xA;Related Anti-patterns&#xA;&#xA;Template Zombies&#xA;&#xA;a href=&#34;https://remark.as/p/tooky.uk/missing-hero&#34;Discuss.../a&#xD;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p><a href="https://tooky.uk/tag:UserStoryAntiPatterns" class="hashtag"><span>#</span><span class="p-category">UserStoryAntiPatterns</span></a></p>

<h2 id="problem" id="problem">Problem</h2>

<p>The team are asked to define the User Stories for an upcoming initiative.</p>

<h2 id="context" id="context">Context</h2>
<ul><li>The team / organisation are undergoing an Agile transformation</li></ul>

<h2 id="forces" id="forces">Forces</h2>
<ul><li>There is an expectation that the User Story template be followed</li>
<li>The team believe they have already have lots of customer knowledge</li>
<li>Product Owner has a strong engineering background</li></ul>

<h2 id="supposed-solution" id="supposed-solution">Supposed Solution</h2>

<p>Create the stories based on the teams internal knowledge of the market and customer. Ensure that the User Story template is adhered to by just using “ The User” where ever it asks for who. When there is a requirement that is internal facing, use an internal stakeholder. e.g. “The Developers” for uprgading dependencies, or “The Product Owner” for internal reports and analytics.</p>

<h2 id="resulting-context" id="resulting-context">Resulting Context</h2>
<ul><li>User Stories become a list of features and tasks that just need to be executed.</li>
<li>There isn&#39;t scope to discuss alternative solutions because their isn&#39;t a shared understanding of exactly who needs the solution.</li>
<li>The product ends up with too many features that aren&#39;t used or difficult to use</li></ul>

<h2 id="alternate-solution" id="alternate-solution">Alternate Solution</h2>
<ul><li>Build a clear picture of the different User and Stakeholder personas.</li>
<li>Focus on those Personas, the problems they have, and what solving those problems will do for them</li>
<li>Bring the team together to create <em>shared understanding</em> and <em>discuss options</em> to solve those problems</li></ul>

<h2 id="related-anti-patterns" id="related-anti-patterns">Related Anti-patterns</h2>
<ul><li><a href="template-zombies">Template Zombies</a></li></ul>

<p><a href="https://remark.as/p/tooky.uk/missing-hero">Discuss...</a></p>
]]></content:encoded>
      <guid>https://tooky.uk/missing-hero</guid>
      <pubDate>Fri, 21 Apr 2023 12:18:43 +0000</pubDate>
    </item>
    <item>
      <title>Template Zombies</title>
      <link>https://tooky.uk/template-zombies?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[UserStoryAntiPatterns&#xA;&#xA;Problem&#xA;&#xA;User stories are missing the context the team needs to have a good discussion.&#xA;&#xA;Context&#xA;&#xA;The team is new to Agile methods&#xA;The organisation is in the process of an Agile transformation.&#xA;&#xA;Forces&#xA;&#xA;Team members are unsure how to reframe their requirements as User Stories&#xA;There is pressure to succeed with the Agile transformation&#xA;Lots of literature about user stories proposes a template that user stories should follow.&#xA;&#xA;Supposed Solution&#xA;&#xA;Proscribe a format that every User Story should conform to. Ensure that every User Story conforms to that format.&#xA;&#xA;Resulting Context&#xA;&#xA;The team becomes overly focussed on ensuring the format is correctly filled in rather than ensuring that the User Story provides enough context for the team to be able to have a useful conversation about it.&#xA;&#xA;  “When you find a project team that is focused on producing a standard document rather than on considering the content of that document, then you are in the land of the template zombies…&#xA;    In the land of the template zombies, form takes precedence. It is not necessary to think about the content of the document. It is not really necessary to think at all. The important thing is to have something—anything—under each of the prescribed headings. Not surprisingly, template zombies are adept in the art of cutting and pasting and ignoring anything that does not fit the dictates of the template.”&#xA;&#xA;Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior; DeMarco et. al&#xA;&#xA;Alternate Solution&#xA;&#xA;The team dicsuss and agree what context is important to them so that they can capture User Stories to discuss later. They may create or use a template that helps them to remember what they have agreed, but do not require it to be used. They document the template and its purpose.&#xA;&#xA;Related Anti-patterns&#xA;&#xA;Missing Hero&#xA;&#xA;a href=&#34;https://remark.as/p/tooky.uk/template-zombies&#34;Discuss.../a&#xD;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p><a href="https://tooky.uk/tag:UserStoryAntiPatterns" class="hashtag"><span>#</span><span class="p-category">UserStoryAntiPatterns</span></a></p>

<h2 id="problem" id="problem">Problem</h2>

<p>User stories are missing the context the team needs to have a good discussion.</p>

<h2 id="context" id="context">Context</h2>
<ul><li>The team is new to Agile methods</li>
<li>The organisation is in the process of an Agile transformation.</li></ul>

<h2 id="forces" id="forces">Forces</h2>
<ul><li>Team members are unsure how to reframe their requirements as User Stories</li>
<li>There is pressure to succeed with the Agile transformation</li>
<li>Lots of literature about user stories proposes a template that user stories <em>should</em> follow.</li></ul>

<h2 id="supposed-solution" id="supposed-solution">Supposed Solution</h2>

<p>Proscribe a format that every User Story should conform to. Ensure that every User Story conforms to that format.</p>

<h2 id="resulting-context" id="resulting-context">Resulting Context</h2>

<p>The team becomes overly focussed on ensuring the format is correctly filled in rather than ensuring that the User Story provides enough context for the team to be able to have a useful conversation about it.</p>

<blockquote><p>“When you find a project team that is focused on producing a standard document rather than on considering the content of that document, then you are in the land of the template zombies…</p>

<p>In the land of the template zombies, form takes precedence. It is not necessary to think about the content of the document. It is not really necessary to think at all. The important thing is to have something—anything—under each of the prescribed headings. Not surprisingly, template zombies are adept in the art of cutting and pasting and ignoring anything that does not fit the dictates of the template.”</p></blockquote>

<p><em>Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior; DeMarco et. al</em></p>

<h2 id="alternate-solution" id="alternate-solution">Alternate Solution</h2>

<p>The team dicsuss and agree what context is important to them so that they can capture User Stories to discuss later. They may create or use a template that helps them to remember what they have agreed, but do not require it to be used. They document the template and its purpose.</p>

<h2 id="related-anti-patterns" id="related-anti-patterns">Related Anti-patterns</h2>
<ul><li><a href="missing-hero">Missing Hero</a></li></ul>

<p><a href="https://remark.as/p/tooky.uk/template-zombies">Discuss...</a></p>
]]></content:encoded>
      <guid>https://tooky.uk/template-zombies</guid>
      <pubDate>Fri, 21 Apr 2023 12:16:07 +0000</pubDate>
    </item>
    <item>
      <title>Over-specific Story</title>
      <link>https://tooky.uk/over-specific-story?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[UserStoryAntiPatterns&#xA;&#xA;Problem&#xA;&#xA;Key milestones are being missed due to defects and rework.&#xA;&#xA;Context&#xA;&#xA;Engineering team say they can&#39;t improve their estimates because the stories are difficult to understand and incomplete.&#xA;Product Owners argue that engineering agreed the stories when they made the estimates.&#xA;&#xA;Forces&#xA;&#xA;The Go-To-Market team are making plans and sharing dates with customers based on development estimates&#xA;Delivery dates are consistently being delayed&#xA;Everyone is asking for more certainty about delivery dates&#xA;&#xA;Supposed Solution&#xA;&#xA;Product Owners spend more time writing more detail into the User Story so that when the Engineering team are ready to estimate they have everything they need.&#xA;&#xA;Resulting Context&#xA;&#xA;When the User Story is first accepted by the Engineering team everyone feels that it is well understood. As development progresses they start to uncover things that hadn&#39;t been considered. The Engineers make assumptions based on their understanding of the User Story. These assumptions lead to unexpected behaviour and defects. This leads to rework, and more missed deadlines.&#xA;&#xA;Alternate Solution&#xA;&#xA;Representatives of the whole team (e.g. devs, testers, Product Owner, design) get together and talk about the problem that needs to be solved. The person that has the most context about tells the User Story. The team build a shared understanding of the problem and their approach to solving it.&#xA;&#xA;Related Anti-patterns&#xA;&#xA;Epic Fail&#xA;&#xA;a href=&#34;https://remark.as/p/tooky.uk/over-specific-story&#34;Discuss.../a&#xD;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p><a href="https://tooky.uk/tag:UserStoryAntiPatterns"><a href="https://tooky.uk/tag:UserStoryAntiPatterns" class="hashtag"><span>#</span><span class="p-category">UserStoryAntiPatterns</span></a></a></p>

<h2 id="problem" id="problem">Problem</h2>

<p>Key milestones are being missed due to defects and rework.</p>

<h2 id="context" id="context">Context</h2>
<ul><li>Engineering team say they can&#39;t improve their estimates because the stories are difficult to understand and incomplete.</li>
<li>Product Owners argue that engineering agreed the stories when they made the estimates.</li></ul>

<h2 id="forces" id="forces">Forces</h2>
<ul><li>The Go-To-Market team are making plans and sharing dates with customers based on development estimates</li>
<li>Delivery dates are consistently being delayed</li>
<li>Everyone is asking for more certainty about delivery dates</li></ul>

<h2 id="supposed-solution" id="supposed-solution">Supposed Solution</h2>

<p>Product Owners spend <strong>more</strong> time writing more <strong>detail</strong> into the User Story so that when the Engineering team are ready to estimate they have everything they need.</p>

<h2 id="resulting-context" id="resulting-context">Resulting Context</h2>

<p>When the User Story is first accepted by the Engineering team everyone feels that it is well understood. As development progresses they start to uncover things that hadn&#39;t been considered. The Engineers make assumptions based on their understanding of the User Story. These assumptions lead to unexpected behaviour and defects. This leads to rework, and more missed deadlines.</p>

<h2 id="alternate-solution" id="alternate-solution">Alternate Solution</h2>

<p>Representatives of the whole team (e.g. devs, testers, Product Owner, design) get together and talk about the problem that needs to be solved. The person that has the most context about tells the User Story. The team build a shared understanding of the problem and their approach to solving it.</p>

<h2 id="related-anti-patterns" id="related-anti-patterns">Related Anti-patterns</h2>
<ul><li><a href="epic-fail">Epic Fail</a></li></ul>

<p><a href="https://remark.as/p/tooky.uk/over-specific-story">Discuss...</a></p>
]]></content:encoded>
      <guid>https://tooky.uk/over-specific-story</guid>
      <pubDate>Fri, 21 Apr 2023 11:46:19 +0000</pubDate>
    </item>
    <item>
      <title>Epic Fail</title>
      <link>https://tooky.uk/epic-fail?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[Part of #UserStoryAntiPatterns&#xA;&#xA;Problem&#xA;&#xA;There are large, loosely defined ideas that the team want to consider for development later.&#xA;&#xA;Context&#xA;&#xA;The team use fixed-length sprints or iterations&#xA;&#xA;Forces&#xA;&#xA;The team must define a 6-12 month delivery roadmap&#xA;The organisation has an annual budgeting cycle&#xA;&#xA;Supposed Solution&#xA;&#xA;The team introduces a backlog hierarchy with a category above User Stories. These items represent things that will be worked on in the future roadmap. They are estimated and tracked independently so the rest of the organisation can plan appropriately.&#xA;&#xA;Resulting Context&#xA;&#xA;The team wastes time and effort tracking and deciding what type of backlog item something is.&#xA;Time is spent doing detailed tracking of something that is deliberately vague and intended to be further understood later.&#xA;Estimates made for these large, uncertain ideas are necessarily unreliable but detailed plans get made on the basis of them by other functions, like marketing.&#xA;&#xA;Alternate Solution&#xA;&#xA;The team spends time to understand their users’, customers’, and stakeholders’ problems and motivations. They identify opportunities for their product to solve those problems and prioritise the opportunities based on the value they provide. Their roadmap reflects the prioritisation of those opportunities and the investment that they want to make to address that opportunity.&#xA;&#xA;Related Anti-patterns&#xA;&#xA;Over-specific Story&#xA;&#xA;a href=&#34;https://remark.as/p/tooky.uk/epic-fail&#34;Discuss.../a&#xD;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p>Part of <a href="https://tooky.uk/tag:UserStoryAntiPatterns" class="hashtag"><span>#</span><span class="p-category">UserStoryAntiPatterns</span></a></p>

<h2 id="problem" id="problem">Problem</h2>

<p>There are large, loosely defined ideas that the team want to consider for development later.</p>

<h2 id="context" id="context">Context</h2>
<ul><li>The team use fixed-length sprints or iterations</li></ul>

<h2 id="forces" id="forces">Forces</h2>
<ul><li>The team must define a 6-12 month delivery roadmap</li>
<li>The organisation has an annual budgeting cycle</li></ul>

<h2 id="supposed-solution" id="supposed-solution">Supposed Solution</h2>

<p>The team introduces a backlog hierarchy with a category above User Stories. These items represent things that will be worked on in the future roadmap. They are estimated and tracked independently so the rest of the organisation can plan appropriately.</p>

<h2 id="resulting-context" id="resulting-context">Resulting Context</h2>
<ul><li>The team wastes time and effort tracking and deciding what type of backlog item something is.</li>
<li>Time is spent doing detailed tracking of something that is deliberately vague and intended to be further understood later.</li>
<li>Estimates made for these large, uncertain ideas are necessarily unreliable but detailed plans get made on the basis of them by other functions, like marketing.</li></ul>

<h2 id="alternate-solution" id="alternate-solution">Alternate Solution</h2>

<p>The team spends time to understand their users’, customers’, and stakeholders’ problems and motivations. They identify opportunities for their product to solve those problems and prioritise the opportunities based on the value they provide. Their roadmap reflects the prioritisation of those opportunities and the investment that they want to make to address that opportunity.</p>

<h2 id="related-anti-patterns" id="related-anti-patterns">Related Anti-patterns</h2>
<ul><li><a href="over-specific-story">Over-specific Story</a></li></ul>

<p><a href="https://remark.as/p/tooky.uk/epic-fail">Discuss...</a></p>
]]></content:encoded>
      <guid>https://tooky.uk/epic-fail</guid>
      <pubDate>Thu, 20 Apr 2023 19:37:35 +0000</pubDate>
    </item>
    <item>
      <title>User Story Anti-Patterns</title>
      <link>https://tooky.uk/user-story-anti-patterns?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[I’ve been planning the Slicing User Stories for Agile Teams course with @Matt. We’ve obviously been talking a lot about user stories, when they work well and … when they don’t.&#xA;&#xA;I’ve started to record some of those less successful approaches as anti-patterns.&#xA;&#xA;I plan to publish them with a  #UserStoryAntiPatterns tag, and I’ll update this post with links to them as I do. I’d be grateful for feedback!&#xA;&#xA;Epic Fail&#xA;Over-specific Story&#xA;Template Zombies&#xA;Missing Hero&#xA;&#xA;a href=&#34;https://remark.as/p/tooky.uk/user-story-anti-patterns&#34;Discuss.../a&#xD;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p>I’ve been planning the <a href="https://maven.com/levain/slicing-user-stories-for-agile-teams" title="Slicing User Stories for Agile Teams">Slicing User Stories for Agile Teams</a> course with <a href="https://mattwynne.net">@Matt</a>. We’ve obviously been talking a lot about user stories, when they work well and … when they don’t.</p>

<p>I’ve started to record some of those less successful approaches as anti-patterns.</p>

<p>I plan to publish them with a  <a href="https://tooky.uk/tag:UserStoryAntiPatterns" class="hashtag"><span>#</span><span class="p-category">UserStoryAntiPatterns</span></a> tag, and I’ll update this post with links to them as I do. I’d be grateful for feedback!</p>
<ul><li><a href="epic-fail">Epic Fail</a></li>
<li><a href="over-specific-story">Over-specific Story</a></li>
<li><a href="template-zombies">Template Zombies</a></li>
<li><a href="missing-hero">Missing Hero</a></li></ul>

<p><a href="https://remark.as/p/tooky.uk/user-story-anti-patterns">Discuss...</a></p>
]]></content:encoded>
      <guid>https://tooky.uk/user-story-anti-patterns</guid>
      <pubDate>Thu, 20 Apr 2023 19:20:30 +0000</pubDate>
    </item>
  </channel>
</rss>