There is a common misbelief that in a project there are multiple groups that want opposite outcomes. This has been haunting company culture for more than 20 years, stating that stakeholders and delivery teams want different things. We must kill this myth.
We must admit instead that there are multiple drivers for the different stakeholder groups:
- Operations demands tracking progress.
- Development wants to extend a system.
- Product managers want flexibility.
- Quality assurance wants measurability.
- Users mainly want a useful system.
It is possible for these, and others, to develop into one solution. We must have a way to work together, valuing customer collaboration
over contract negotiation.
Instead of falling into — and failing at — playing "telephone" (passing along misinformation through whispers), move to the Agile value of individuals and interactions
over processes and tools.
Bringing together the multiple drivers through talking and demonstrating, very often a proof of concept is more powerful than multiple pages about what the solution is not — i.e., out of scope. Keeping in mind the value of a working product over documentation, a requirements document should be there to help, and it should only be used if it is needed and useful. (Sometimes we feel that it becomes the goal or a negotiation tool, rather than an enabler.)
I usually refer to the concept of the last responsible moment
, meaning that the team defers writing down most details of the features until just before development. This reduces waste while keeping the items relevant, on time, and to the point, and it enables responding to change
over following a plan.
A user story is the way to bring the focus to the users. A user story is a type or style of a product backlog item. The aim is to deliver progress in manageable pieces of work so that one can not block another, and so that there are continuous improvements made over time.
How can we get started with user stories?
Let's first define them. A user story captures a description of a feature from an end-user's perspective. So we need to write them in a way that expresses the value of the feature to the consumer.
My 3x3 rule for a user story:
- Components: They are made up of a written description/statement, discussions about and context of the story, and acceptance criteria expectations and tests.
- Statement: Here you want to capture who is interested, what the idea is, and why it is important.
- Contents: Cover items and needs such as data bases, business logic, and user interface.
In my experience, you are better off having multiple smaller stories rather than one story that is too large. If the concept of a feature is too large and not ranked high enough in the backlog, it is often referred as an epic. Over time and as it creeps up the ranking, that epic will have multiple stories and in fact will be a way to group those stories.
Your stakeholders (ideally acting via a sole product owner) write the stories in consumer value and language, rather than in technical language. This also helps us appropriately rank the items in the backlog.
The Development Team estimates each item, as they are the experts in being closer to the technology and to any uncertainty on specifics that may evolve during the delivery of these smaller stories.
Together, the product owner and Development Team work on story refinement, seeking clarification before committing to any item in a sprint. Together they also review the completed items — where, naturally, new stories will emerge.
Why user stories?
Here is some food for thought about user stories:
- They support iterative development, which enables inspection and adaptation to change.
- They emphasize collaboration rather than isolated documentation.
- They encourage detail only when you are close enough to understand what is needed, which reduces waste.
- They are bite-sized supports of all artifacts as well as events of the Scrum framework.
- They generally focus on the end consumer of your product.