A pervasive anti-pattern in many companies is Team-level backlogs replete with technical tasks. Not a single real User Story in sight. This is what I call “Tasks masquerading as User Stories”. There are so many things wrong with this, I don’t know where to begin!
I’ve heard it all and seen it all.
“We write technical stories.”
“We’re different – we just capture what we need to do from a Dev perspective.”
“The requirements are captured as technical work items.”
“We spend months on end writing a big thick BRD and then just go from there to technical tasks.”
And the all-pervasive:
“As a developer, I want to add the XYZ method into the ABC class, so that the code works.”
STOP THE MADNESS!
Why User Stories?
The User Story approach is a wonderful lightweight Agile technique for capturing the essence of a requirement. User Stories are written from the perspective of the end user, not someone on your Dev team! They allow us to establish empathy with our users.
User Stories capture the WHAT. Technical tasks are associated with the User Story and capture the HOW. Don’t mix up the two. Technical tasks are the result of DECOMPOSING User Stories, not User Stories themselves!
User Stories require conversations in order to understand the details associated with the actual requirement. Over these conversations, we build up tacit awareness and deep understanding of the requirement. This reduces our documentation needs significantly.
We should always model our requirements from our user’s perspective. This establishes empathy with the customer and helps to ensure we are building the right product.
The Silent Killer – Tasks Masquerading as User Stories!
Here are the problems when capturing requirements in the form of technical tasks:
- Lack of empathy with the user – starting with an emphasis on development instead of the user
- Ignoring the conversation part of the 3 C’s (Card – Conversation – Confirmation)
- Presumptuous solutioning – missing opportunities for better/simpler solutions
- Building the wrong solution for our customer
- Disconnect between the purpose of the work and the work itself
Wrap
For a concise description from the master of User Stories, check it out here. For a healthy approach to Agile documentation, go here.
Need I go on? Stop the madness. Take a courageous stand against technical tasks masquerading as User Stories. Now. Thanks!