Steve Tooke

userstoryantipatterns

#UserStoryAntiPatterns

Problem

The team are asked to define the User Stories for an upcoming initiative.

Context

  • The team / organisation are undergoing an Agile transformation

Forces

  • There is an expectation that the User Story template be followed
  • The team believe they have already have lots of customer knowledge
  • Product Owner has a strong engineering background

Supposed Solution

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.

Resulting Context

  • User Stories become a list of features and tasks that just need to be executed.
  • There isn't scope to discuss alternative solutions because their isn't a shared understanding of exactly who needs the solution.
  • The product ends up with too many features that aren't used or difficult to use

Alternate Solution

  • Build a clear picture of the different User and Stakeholder personas.
  • Focus on those Personas, the problems they have, and what solving those problems will do for them
  • Bring the team together to create shared understanding and discuss options to solve those problems

Discuss...

#UserStoryAntiPatterns

Problem

User stories are missing the context the team needs to have a good discussion.

Context

  • The team is new to Agile methods
  • The organisation is in the process of an Agile transformation.

Forces

  • Team members are unsure how to reframe their requirements as User Stories
  • There is pressure to succeed with the Agile transformation
  • Lots of literature about user stories proposes a template that user stories should follow.

Supposed Solution

Proscribe a format that every User Story should conform to. Ensure that every User Story conforms to that format.

Resulting Context

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.

“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…

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.”

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior; DeMarco et. al

Alternate Solution

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.

Discuss...

#UserStoryAntiPatterns

Problem

Key milestones are being missed due to defects and rework.

Context

  • Engineering team say they can't improve their estimates because the stories are difficult to understand and incomplete.
  • Product Owners argue that engineering agreed the stories when they made the estimates.

Forces

  • The Go-To-Market team are making plans and sharing dates with customers based on development estimates
  • Delivery dates are consistently being delayed
  • Everyone is asking for more certainty about delivery dates

Supposed Solution

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.

Resulting Context

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'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.

Alternate Solution

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.

Discuss...

Part of #UserStoryAntiPatterns

Problem

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

Context

  • The team use fixed-length sprints or iterations

Forces

  • The team must define a 6-12 month delivery roadmap
  • The organisation has an annual budgeting cycle

Supposed Solution

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.

Resulting Context

  • The team wastes time and effort tracking and deciding what type of backlog item something is.
  • Time is spent doing detailed tracking of something that is deliberately vague and intended to be further understood later.
  • 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.

Alternate Solution

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.

Discuss...

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.

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

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!

Discuss...