Abstract
The book is a narrated algorithm for the development process from idea to implementation using agile techniques. The process is broken down into steps, with methods outlined for each stage. The author notes that most of the methods are not original and does not claim originality. However, the good writing style and some coherence of the process make the book very useful.
The key technique of user story mapping is to structure ideas and tasks as the user navigates through the process.
The process can be described in different ways. You can structure the steps based on achieving key value, or you can simply present a typical working day of users as they use the system. The author emphasizes that processes should be narrated as a user story on the process map, which is what gives the name 'user story map'.
Who needs this
For IT analysts and project managers. A must-read. It is easy and pleasant to read, and the book is of medium size.
Review
In its simplest form, here’s how it works.
A visitor arrives at the café, chooses dishes, places an order, receives food, eats, and pays.
Requirements can be written about what we want from the system at each stage.
The system should display a list of dishes, detailing each dish's ingredients, weight, and price, and allow for items to be added to the cart. Why are we confident in these requirements? In the 'standard' requirements description, this is not specified, which creates risks.
Performers who do not understand the need for this usually do not deliver what is necessary. Those not involved in the ideation process are also not invested in the outcome. Agile suggests focusing primarily not on the system, but on people, on consumers, their tasks, and goals.
We create personas, adding details for empathy, and begin to narrate stories from the perspective of these personas.
Office worker Zakhar went for lunch and wants a quick bite. What does he need? The idea is that he probably wants a business lunch. Another idea is that he wants the system to remember his preferences because he is on a diet. Another idea: He wants coffee to be served immediately, as he is used to drinking coffee before lunch.
There is also a business (org character - a character representing the interests of an organization). The business wants to increase the average check, increase the purchase frequency, and boost profit. The idea is to offer unusual dishes from a certain cuisine. Another idea is to introduce breakfasts.
Ideas can and should be specified, transformed, and presented as user stories. As an employee of the business center, Zachar, I want the system to recognize me so that I receive a menu tailored to my preferences. As a waiter, I want the system to notify me when to approach the table, ensuring the client is satisfied with prompt service. And so on.
Tens of stories. Then prioritization and backlog? Jeff points out emerging issues: getting bogged down in minor details and losing conceptual understanding, plus prioritizing functionalities creates a disjointed picture due to misalignment with goals.
The author's path: We prioritize results, not functionalities = what the user ultimately receives.
An obvious yet non-obvious point: the prioritization session is not held with the entire team, as it is ineffective, but rather with three people. One is responsible for the business, the second for user experience, and the third for implementation.
We highlight the minimum necessary to solve one user task (minimum viable solution).
We detail the first priority ideas using user stories, design sketches, constraints, and business rules on the user story map by narrating and discussing with the team what is needed by personas and stakeholders at each step of the process. Other ideas remain unrefined in the backlog of possibilities.
The process is written in the form of cards moving left to right, with ideas on the cards under the steps of the process. It is essential to discuss the entire story's progress together with team members to foster mutual understanding.
This method of working creates a coherence that aligns with processes.
The generated ideas need to be validated. A non-team member puts on the persona's hat and spends a day in the persona's mind, solving their task. There may be a scenario where they do not see the existing developments, creating cards anew while the team discovers alternatives.
Next, detailing for assessment takes place. For this, three people are sufficient: a user experience lead, a developer, and a tester with a favorite question: 'What if...'.
At every stage, discussions revolve around the user story process map, which helps maintain a coherent understanding of the user’s task.
Does the author consider documentation necessary? Yes, it is needed, but more as notes to recall what was agreed upon. Involving an outsider requires further discussion.
The author does not delve into the sufficiency of documentation, emphasizing the necessity of discussions instead. (Yes, documentation is needed, despite claims from those not deeply versed in agile). Focusing on just part of the possibilities can lead to the need for a complete overhaul of the entire system. The author points to the risk of over-processing when an idea doesn’t hit the mark.
To mitigate risks, it’s essential to quickly obtain feedback on the product being developed to minimize the damage of creating 'the wrong' product. A rough idea was sketched — validated with the user, a rough user interface prototype was created — validated with the user, etc. (Additionally, it briefly mentions how to validate software prototypes). The goals of software creation, especially in the early stages, are to learn through rapid feedback acquisition; consequently, the first created product is a draft positioned to prove or disprove a hypothesis. (The author references Eric Ries' work 'The Lean Startup').
The story map facilitates communication when implementation is handled by multiple teams. What should be on the map? What is needed to support the conversation: not only user stories (who, what, why) but also ideas, facts, interface sketches, etc.
By dividing cards on the story map into several horizontal lines, tasks can be segmented into releases — highlighting the bare minimum, a layer for functionality growth, and embellishments.
We discuss the stories on the process map.
An employee came for lunch.
What does he want? Speed of service. He wants his lunch to be waiting for him at the table or at least on a tray. Oops — a missed step: the employee decided to eat. He logged into the system and chose a business lunch option. He saw the calorie count and nutritional values to stick to his diet and avoid gaining weight. He looked at pictures of the dish to decide whether he would eat at this place or not.
Next, is he going to pick up lunch and eat? Or would he prefer lunch delivered to the office? Then the next step in the process is choosing where to eat. He wants to see the delivery time and cost to decide where to spend his time and energy — going downstairs or staying at work. He wants to see the café's busyness to avoid crowds.
Then the employee arrives at the café. He wants to see his tray so he can grab it and go straight to lunch. The café wants to collect payment to profit from the service. The employee wants to spend the least amount of time on transactions so as not to waste precious time. How can this be done? By paying in advance, or conversely, remotely after the service. Or paying on the spot using a kiosk. Which of these is the most essential? How many people are willing to pay for lunch with a credit card? How many would trust the storage of their card number for repeat payments at this cafeteria? Without field research, it's unclear; testing is needed.
At every step of the process, functionality must somehow be ensured, for which a persona must be taken as a basis to choose what is more important to him (that very trio of selectors). If the story is followed through to the end, a viable solution is produced.
Next comes detailing. The customer wants to see the café's busyness to avoid waiting in lines. What exactly does he want?
To see the forecast for how many people will be there in 15 minutes when he arrives.
To check the average service time in the café and its dynamics over the next half hour.
To observe the situation and the dynamics of table occupancy.
But what if the forecasting system gives an unclear result or stops working?
To watch the queues in the café via video, as well as table occupancy. Hmm, why not prioritize this?!
The author suggests a small exercise for practicing: try to visualize what you do in the morning after waking up. One card = one action. Broaden the cards (instead of grinding coffee — drink an energizing beverage), to eliminate individual details, focusing not on the method of execution, but on the goal.
Who is this book for? It is essential reading for IT analysts and project managers.
Applications
Discussion and decision-making are effective in groups of 3 to 5 people.
Write on the first card what needs to be developed, on the second — fix what was done on the first, and on the third — fix what was done on the first and second.
Prepare stories like cakes — not by writing a recipe for making them, but by finding out for whom, on what occasion, and for how many people the cake is intended. If breaking down the implementation, do so not into making layers, cream, etc., but into creating small ready-made cakes.
Software development is similar to making a film, where it is essential to craft and polish the script, organize the scene, actors, etc., before shooting begins.
There will always be a lack of resources.
20% of efforts yield significant results, 60% result in unclear outcomes, and 20% of efforts are counterproductive — that's why it's important to focus on learning and not despair in case of negative results.
Engage directly with the user, put yourself in their shoes. Focus on specific problems.
Detailing and refining the story for assessment is the most tedious part of Scrum; make discussions standing in an aquarium mode (3-4 people discuss at the board, and anyone who wants to participate replaces someone).
Source: habr.com
