A Common Pitfall With User Stories

(Netherlands)

September 16, 2015

The concept of user stories is a well-known tool for describing requirements. In a simple format, it captures the ‘who’, ‘what’ and ‘why’ of a requirement. User stories have their roots in Extreme Programming (XP) and are an often-used tactic within Scrum. In 2001, Ron Jeffries proposed the Three C’s formula as a guide to capturing the essence of user stories: Card, Conversation, and Confirmation.

A card is a physical token giving tangible and durable form to what would otherwise only be an abstraction. A conversation is taking place at a different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation. The confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally[1].

The concept of user stories can be very powerful when the Three C’s formula is respected. Especially within a complex environment it’s crucial to understand the idea behind user stories and use it properly. The problem however is, that quite often this isn’t the case. The cards become digital tokens (hidden in tools like e.g. Jira, TFS) that remain an abstraction. The conversation hardly takes place via face-to-face communication. The valuable dialogue between the customer, users, Product Owner and Development Team often doesn’t occur. Therefore it also lack the exchange of thoughts, opinions and feelings to truly grasp the essence of the user story. The confirmation often is surrounded with misunderstandings, because of the lacking conversation. This causes the stakeholders and development team not having a shared understanding of the ‘done state’ of the requirement.

The essence of a user story is to discuss the story with the user. Ideally it’s the Development Team that discusses the desired functionality with the actual user. The more concessions you do to this ideal state, the less powerful the concept of user stories will be.

What is your experience with this? Do you recognize the pitfall I describe?

[1] https://en.wikipedia.org/wiki/User_story

What did you think about this post?

Share with your network

Comments (6)

Brandon Wittwer

08:17 pm September 16, 2015

Thanks for sharing with the community. On the topic of face-to-face meetings, I would say is the most important resource in a scrum team. An available and expressive product owner is a must if you don't want to re-work and slip velocity. Scrum harbors a relationship between the development team and the product owner, and as with any relationship, communication is key.
You've stated, and I've heard many times in the past, that having a tangible entity that represents the workload is important. Digital representations are not tactile and therefore remain an abstraction that is less concrete. Our team uses a number of tools to track work throughout a scrum project. Currently Trello holds our backlog items, and the taskwork flows into TFS for changeset tracking. Having all cards on our person at all times in our mobile devices and at our desks helps story momentum when questions are asked and answered on cards. That instant feedback without waiting for the next grooming session really speeds us along the process of finalizing acceptance criteria and resolving issues mid-sprint as things evolve. I would argue that the physical card taped to a wall somewhere is ineffectual at representing the complexities of the story's progression from backlog to sprint to DoD. Digital cards fit well in our digital life.
Again, communication is key in any relationship. The tool that makes you the best communicator is the one that's going to make your team successful in my opinion.
Thanks again for your post.

Vladimir Tisma

12:15 pm September 21, 2015

Recognize - absolutely. Normally, JIRA contains an abstraction of user's expectations, while development team builds based on one or more assumptions (frequently false), and confirmation is either rejection and turning to something else or from-scratch reiteration if time allows.

Fredrik Carleson

01:51 am September 22, 2015

Individuals and interaction over processes and tools off course. A system can never replace human interaction and face to face communication is always more effective in my opinion.By talking to each other we build a common taxonomy and understanding through immediate feedback loops. This is very hard, if not possible to do by using a tool or written language.

Jörg Keller

08:40 am September 22, 2015

Sometimes it is less a pitfall than laziness. Instead of writing long specification documents you are officially allowed to keep it short, enter just a single sentence into JIRA ;-)

The necessary shift of communication from ineffective writing to the more direct face-to-face communication is much harder.

Alex Ballarin

07:16 pm March 7, 2016

Very good (again) Barry.

I DO agree that many teams that don't know the real meaning of User Stories (3 C's or even 5 C's according to Jeff Patton) and they focus their attention on the format (WHO/WHAT/WHY) or the tool (Jira or other). Insisting on the real purpose of User Stories is perhaps the biggest help you can do while teaching them.

Elaine Mikesell

12:49 pm May 26, 2017

Is there template that teams can use to elaborate on a user stories, including screen mockup, associated business rules, etc.?