User Stories and Use Cases - a pair of agile red herrings

I would like to start a conversation around User Stories. I am finding their superficial adoption meaning there is more and more admin and less and less useful understanding in teams.

User Stories are a bit of a dead end. They were originally intended as provoking a conversation and the structure came later. They have become de-facto standards for documenting requirements without generating discussion and understanding.

With User Stories I find that people don't understand:

1. the "As a" part whereas "Actor" is much clearer
2. the "So that" part and interpret this any way they wish

So they just fill those bits in any old how and describe the functionality in the middle. All the User Story mapping nonsense is just filling in the gaps between isolated conversations.

They get too big and then they are “Epics”; another term that needs to be described and de-bunked. “epics are themes” “no themes contain epics” "but stories have themes and are part of epics” “our tool can’t represent those dimensions” blah blah blah.

Surely this is waste, A waste of time and creativity and it should be challenged. The challenge should be: "how do we as a team best represent what we need to do"? How do we make sure it continues to be adapted as we get better at what we do.

Making a cuppa activity diagram

From a personal perspective I find conversations around meeting the user objectives are facilitated by much techniques that avoid User Stories and, I often discuss who is the "Actor" in order to understand profiles and authorisation levels, but then again I was a OO / UML fan back in the day. I discuss what the actors want to achieve, and yes I consider the consumers of the information created not just the creator, they are also actors. I discuss the possible steps to get to a good outcome and at that point the features used in order for the actor to get there. User stories always get in the way and verbose Use Cases are difficult to generate during a conversation.

My conclusion has been to have a one liner without the User Story structure. This is in an ordered list.  If it needed next, we have a conversation, I keep these high level and use a visual technique to gain a common understanding at the level required. For me I often use an Activity Diagram style drawing on a whiteboard, which I then photograph and stick on a wall to be scribbled over as we deliver. This is my feature description. 

Please don't follow what I do because I say so, but please spare a moment to think about how you get the right thing done without waste.

As an aside if you know Use Cases then you know that an Activity Diagram is graphical view of a use case so contains the same information so I lean more in the Use Case direction, however by not have them formally "written up” it avoids unnecessary admin.