Waterfall Stories

As a coach helping organizations uncover new ways of working to improve their outcomes and value delivered, I often feel like an anthropologist.

• Observing how people interact with each other.
• Mapping out how they get work done.
• Examining the artifacts that get produced along their value stream.
• Trying to understand why they do the things they do.

Looking for hints or smells that collectively define their existing culture.

Like code smells that reveal potential weaknesses in software, I often look for culture smells that reveal potential weaknesses in the way work gets done.

One such culture smell I’ve come across in many organizations is the devolution of a User Story to simply a Story.

A typical User Story is expressed as follows:

“As <a user>, I want to <perform an action> so that <I can accomplish a goal>”

When we refer to User Stories as Stories, it’s a slippery slope and it doesn’t take long to forget about the User.

The Story then starts to look more like this,

“<Perform an action> so that <a goal is accomplished>”

And, shortly after that, without a User, the goal gets forgotten or ignored and dropped too, resulting in a Story that now looks like this,

“<Perform an action>”

Looks more like a boring Task than an interesting Story.

And if that isn’t enough of a transgression against the original intent of a User Story, I’ve seen it get even worst.

I’ve seen User Stories turn into Waterfall Stories such as

• “Assessment” Stories
• “Analysis” Stories
• “Design” Stories
• “Implementation” Stories
• “Testing” Stories

It’s as if the concept of User Stories is being hacked to prop up a traditional waterfall methodology.

Waterfall in Agile clothing!

Arrrgh!!!