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