How User Flows, UX Diagrams and other Artifacts Can Play Well With User Stories

A question was asked on linkedin, “If you’re using User Stories to describe your product, how and where do you document the use cases, entities, flows, UI and so on?”

The user story is not just a one sentence description of a piece of functionality. It is, in fact, “The promise of a future conversation.” That is to say the user story is more of a conversation starter than “something to be tossed over the wall to the development team and coded.” So without a conversation around the user story, its not a user story, its a woefully incomplete spec.

The user story itself consists of 3 Cs, “The Card”, “The Conversation”, and “The Confirmation.”

When most people talk about “User Stories”, they are talking about “The Card”, because user stories used to be written on index cards. But the card is just a token reminder to have a conversation.

The Conversation is where the real meat happens.

Its where the team asks any and all questions associated with the user story in order to get a sense of whats really needed, what the technical cost is, what the priority is, and any other required parameters. Most importantly, there is a shared sense of the “Definition of Done”, which means EVERYTHING NECESSARY to deliver that user story is outlined in the definition of done. That includes product documentation (if necessary), specifications (if necessary) and acceptance criteria.

The Confirmation is where we all take a look at what was delivered and confirm that it is what we wanted to deliver.

In Scrum, this usually happens during the sprint review. The feedback loop is the most important part of the process, in my opinion, because it prevents us from operating in an open loop for too long.

Back to the Original Question

Now to bring it all back and directly address your original question, “How and where do you document the use cases, flows, UI and so on if the customer wants it?” If the customer wants it, then the customer has deemed these items to have value. If these items have value then they are a part of the “Definition of Done” for that story.

So when the User Story gets broken down into its component tasks, those additional valuable artifacts are part of the work to be done, and thus part of the value to be delivered, and thus part of the acceptance criteria and the feedback loop when these finished items are reviewed with the Product Owner and/or the Customer.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply