A Common Pitfall With User Stories
Barry Overeem
Co-founder The Liberators & Columinity: a product that helps teams improve based on scientific insights. 🚀
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). In 2001, Ron Jeffries proposed the Three C’s formula as a guide to capture 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 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? If so, how have you handled it?
[1] https://en.wikipedia.org/wiki/User_story
Software developer : Scrum Master : Team Developer
8yIndeed, the described problems are often encountered. During my trainings I always try to emphasize the communication is key, also (especially!) when working with User Stories.
Sr Agile Transformatie Coach / Scrum / DevOps / Trainer bij Agile Advies
8yWell said Barry. I think it all starts with the word "requirement". I always emphasis that User Stories are not requirements. A good time to make requirements concreet is during the Sprint, in which the User Story is implemented. When doing so you might ask yourself if writing down the requirements is useful. I worked in the medical sector where you have to have documented requirements and link them to testcases, so yes there it was a "must-have". But often writing down requirements is waste and only done, because "we have always done it that way" ;-)
I've mostly done projects where the end-user was part of the organisation I was stationed at. One of the tricks I've used to "force" good user stories is Hallway Usability Testing (http://wall-skills.com/2014/hallway-usability-tests/), which results in the end-user having a large amount of input and say in both the Backlog and the DoD.
Agile Transformation | Business Agility | FinTech | Scrumthusiast
8yGood ones, Adrian. I have a few more, of how it's not supposed to happen: 8. The Product Backlog Item is totally clear...to the most senior person on the team, but not for the rest of the team...
Systemic Change Agent | Practical & Pragmatic Software Improvements | Financial Throughput Generator | Scientist | Humanist
8yGood points Adrian.