How to tell a good user story?
This is not new, mankind loves stories. It is in this form that ideas are shared, that they give birth to projects, and become concrete in realisations that are the fruit of several people.
Stories are strong, powerful, captivating... if you are a good storyteller, we listen to you with pleasure. Often I am asked for advice, I am presented with a problem, I am expected to bring an answer, a solution, or rather, I feel that the other person knows that he or she will have an answer. Looking back, I realise that success is in listening, in involvement, in the ability to translate a need, in the cohesion of the group in charge of producing a result.
When the spoken word becomes a narrative, concepts make your project more robust, more interesting, more complete... How do you get the stakeholders to agree, how do you guide the developers, how do you make sure that the client will get the requested product? How to keep a clear and understandable record? If you are asking yourself the same questions then read this article which in 2 minutes will give you some food for thought or a starting point.
In the course of my professional activity, I have followed a classic path as a developer, as a functional analyst, I have participated in project management, I have met people from other professions, or from other companies. But also, I guided users in learning as well as in expressing their problems and expectations...
What's the common denominator in all this? Communication! The language that allows everyone to understand each other or make themselves understood. It is important to avoid frustrations and blockages and, on the contrary, to encourage exchange, the emergence of new ideas, and create a favourable work climate. You have to develop a certain sensitivity towards others, but that's not enough!
In computer science in particular, we have developed techniques, methods, and good practices to help us gain experience. Agile offers us very explicit user stories. Built to be understood, to give meaning and value. Sometimes we wonder how to do it, how to structure our thoughts. What trick or tip can complement my expertise? How did things evolve?
To write a user story, I pay attention to the UML Use Case. It allows us to focus the action on an actor and the result obtained according to a path, a determined process.
This use case serves me on 3 levels of the project:
The definition of the need so that the developer can code
Functional test definition for the developer and the quality engineer
Definition of the functionality for writing a user manual, training, and support
Perhaps it is already too detailed, too documented compared to the Agile approach?
With Agile, the user story is a digest formalised by the phrase "as ... I want ... in order to ...".
The development team with the help of the product owner will feed this story with more context and precision. The backlog will be progressively completed and enriched during the sprints. Agile refers to a development style, TDD, where 3 activities are intimately linked: coding, testing (in the form of unitary writing tests), and design (in the form of refactoring).
If like me you like a clear, easy, structured scheme I advise you to use the 'Gherkin language'.
ATDD (Acceptance Test-Driven Development) is an iterative and incremental software development approach. From this approach comes the 'Gherkin language' from which one of the main tools on the market is 'Cucumber'. The principle is to write a document in natural language and understandable by all project stakeholders. Gherkin introduces the notion of ubiquitous language.
This is reminiscent of the UML use case and user story...
DDD (Domain-driven Design)
The world of software development has also evolved on the client-side. IT has become more and more popular, the customer is more and more informed, and in large companies, the definition of needs is complex, targeted and often already impregnated with the jargon of the sector.
When writing a user story becomes a difficult task, how do you solve the blank sheet syndrome?
Call in an expert, a Subject Matter Expert (SME). I advise you to use the DDD or domain-driven design. It is neither a framework nor a methodology, but rather a writing approach.
Domain-driven design (DDD) is a design approach that was introduced by Eric Evans in 2003 and is based on two principles:
Any complex business design must be based on a domain model.
Focus first on the core business and its logic instead of technical constraints.
DDD applies particularly well to Agile because the team must produce user stories that represent the user requirements to be implemented. It is also an opportunity to define the shared language (Ubiquitous Language). It is important that all the actors involved in the construction of the product are present during the user story framing workshops, as each speaker can contribute and become imbued with the common language.
On the one hand, a story is the starting point for expressing a need. On the other hand, there is the collection of information. Both simple and complicated. It is up to us to choose how we are going to proceed in the framing workshops according to the field, the complexity, the expectations.
One approach is not unique, is not better than another, however, one of its objectives is to define a vision and a language shared by all those involved in the construction of an application, in order to better understand its complexity. The Agile development team will decide how it will be organised. Developing ideas is a matter of communication and language.
We can take advantage of: