Abstract
The book is a narrated algorithm for carrying out the development process from idea to implementation using agile techniques. The process is decomposed into steps and at each step methods for the process step are specified. The author points out that most of the methods are not original, without claiming originality. But the good writing style and some integrity of the process make the book very useful.
The key technique of the user story map is the structuring of ideas and staging as the user goes through the process.
At the same time, the process can be described in different ways. You can build steps as you achieve a key value, or you can simply take and imagine the working day of users as it goes through using the system. The author focuses on the fact that processes need to be stated, spoken in the form of a user story on a process map, which was the name of the user story map.
Who needs it
For IT Analysts and Project Managers. A must read. It is easy to read and pleasant, the book is medium in size.
Write Your Review
In the simplest way, how it works.
A visitor comes to a cafe, chooses dishes, places an order, receives food, eats, pays.
We can write the requirements that we want from the system at each stage.
The system should show a list of dishes, each dish has a composition, weight and price, and be able to add it to the cart. Why are we confident in these requirements? This is not described in the βstandardβ requirements description and this creates risks.
Performers who do not understand why this is necessary usually do the wrong thing. Performers who are not involved in the process of creating an idea are not involved in the result. Agile says, so let's focus primarily not on the system, but on people, on consumers, their tasks and goals.
We make personas, for empathy we give them details, and from the side of persons we begin to tell stories.
Zakhar, an office worker, went to lunch and wants a quick bite to eat. What does he need? The idea is that he probably wants a business lunch. Another idea is he wants the system to remember his preferences because he is on a diet. Another idea. He wants coffee to be brought to him right away, because he is used to drinking coffee before dinner.
And there is also business (orgsonage - a character representing the interests of some organization). The business wants to increase the average check, increase the frequency of purchases, and increase profits. The idea - let's offer unusual dishes of some kind of cuisine. Another idea - let's introduce breakfast.
Ideas can and should be concretized, transformed and presented in the form of a user story. As an employee of the Zakhar business center, 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 come to the table so that the customer is satisfied with the fast service. And so on.
Dozens of stories. Further prioritization and backlog? Jeff points out the problems that arise: getting bogged down in small details and loss of conceptual understanding plus feature prioritization creates a jagged picture due to inconsistency with goals.
The way of the author: We prioritize not the functionality, but the result = what the user gets in the end.
An obvious non-obvious point: the prioritization session is not held by the whole team, because it is inefficient, but by three people. The first is responsible for business, the second for user experience and the third for implementation.
We select a minimum for solving one user task (the minimum viable solution).
Detailing first priority ideas with user stories, design sketches, constraints, and business rules on a user story map by telling and discussing with the team what people and stakeholders need at each step of the process. We leave the rest of the ideas unanalyzed, in the backlog of opportunities.
The process is written in the form of cards from left to right, and the ideas on the cards are under the steps of the process. Be sure to discuss the path of the whole story together with the team members for the emergence of mutual understanding.
Working through in this way creates consistency with the processes.
The resulting ideas need to be tested. The non-team member puts on the persona's hat and lives in the person's day in his head, solving his problem. It is possible that he does not see the developments, creating cards anew, and the team discovers alternatives.
Then comes the detailing for evaluation. Three people are enough for this. Responsible for user experience, developer, tester with a favorite question: "What if ...".
At each stage, the discussion moves along the process map of the user's story, which allows keeping the user's task in mind to create a coherent understanding.
Is documentation necessary according to the author? Yes, it's needed. But as notes, allowing you to remember what we agreed on. The involvement of a person from outside again requires discussion.
The author does not delve into the topic of documentation sufficiency, focusing on the need for discussion. (Yes, documentation is needed, no matter how people who are not deep in understanding agile would argue). Also, the study of only a part of the capabilities may lead to the need for a complete redesign of the entire system. The author points out the risk of over-elaboration in the case when the idea was not guessed right.
To remove risks, it is necessary to quickly receive feedback on the product being created to minimize the damage of creating the βwrongβ product. We made a sketch of an idea - validated it for the user, a sketch of interface prototypes - validated it for the user, etc. (Separately, it is slightly indicated how to validate program prototypes). The goals of creating software, especially at the initial stage, are learning through obtaining quick feedback, respectively, the first product created is sketches that are able to prove or disprove a hypothesis. (The author relies on the work of Eric Rice βStartup on the Lean Methodologyβ).
A story map helps to improve communication if the implementation is provided by several teams. What should be on the map? Just what you need to keep the conversation going. Not only a user story (who, what, why), but ideas, facts, interface sketches, etcβ¦
By dividing the cards on the history map into several horizontal lines, you can divide the work into releases - select the very minimum, a layer of functional enhancement and bows.
We speak stories on the process map.
An employee came for lunch.
What does he want? Service rates. So that his lunch is already waiting for him on the table, or at least on a tray. Oops - a missed step: the employee wanted to eat. He logged in and chose the business lunch option. He saw the calorie content and nutritional value to keep a diet and not get fat. He saw pictures of the dish to decide whether he would eat at that place or not.
Is he going to get lunch and dinner next? Or maybe he will have lunch delivered to the office? Then the step of the process is choosing a place to eat. He wants to see the time when he will be delivered and how much it will cost, in order to choose where to spend his time and effort - going downstairs or going to work. He wants to see how busy the cafe is, so as not to push in the queues.
Next, the employee came to the cafe. He wants to see his tray so he can take it and go straight to dinner. The cafe wants to accept money to make money on the service. The employee wants to lose a minimum of time on settlements with the cafe, so as not to waste precious time without use. How to do it? Pay in advance or vice versa after service remotely. Or pay at the moment using the kiosk. Which of these is the most important? How many people are willing to pay for lunch with a bank card? How many people would trust this diner to keep their card number for recurring payments? Without a field study, it is unclear whether testing is needed.
At each step of the process, you need to somehow provide functionality, for this you need to take some person as a basis and choose what is more important to him (the same three electors). Passed the story to the end = made a viable decision.
Next comes the detail. The client wants to see the workload of the cafe, so as not to push in the queues. What exactly does he want?
See the forecast of how many people will be in 15 minutes, when he gets there
Watch the average service time in a cafe and its dynamics for half an hour ahead
See the situation and the dynamics of table occupancy
But what if the prediction system gives an incomprehensible result or stops working?
Watch through the video of the queue in the cafe, as well as the occupancy of the tables. Hmm, why not do that in the first place?!
The author points to a small exercise to work out the practice: try to imagine what you are doing in the morning after waking up. One card = one action. Enlarge the cards (instead of grinding coffee - drinking an invigorating drink) to remove individual details, focusing not on the method of implementation, but on the goal.
Who is this book for? IT analysts and project managers. A must read.
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 - correct what was done in the first, on the third - correct what was done in the first and second.
Cook stories like cakes - not writing out a recipe for making, but finding out who, for what reason, for how many people the cake. If you break down the implementation, then not into making cakes, cream, etc., but into making small ready-made cakes.
Software development is like making a movie, where you have to carefully develop and polish the script, set up the scene, the actors, etc. before filming starts.
Resources will always be in short supply.
20% of the efforts give a tangible result, 60% give an incomprehensible result, 20% of the efforts go to the detriment - this is why it is important to focus on learning and not despair in case of a negative result.
Communicate with the user directly, feel yourself in his shoes. Focus on some issues.
Detailing and working out the story for evaluation is the most dreary part of scrum, make the discussions standing in the aquarium mode (3-4 people discuss at the board, if someone wants to participate, he replaces someone).
Source: habr.com