Patton Jeff. User stories. The art of agile software development

annotation

The book is an algorithm for carrying out the development process from idea to implementation using agile techniques. The process is arranged in steps and at each step the methods for the process step are indicated. The author points out that most of the methods are not original, not claiming originality. But a good writing style and some integrity of the process make the book very useful.

The key technique of user story cards is the structuring of ideas and statements as the user proceeds.

At the same time, the process can be described in different ways. You can build steps as you achieve key value, or you can simply take and imagine the users' working day as it passes using the system. The author focuses on the fact that the processes need to be expressed, pronounced as a user history on the process map, which was the name of the user history map.
')

Who needs it

For IT analysts and project managers. Be sure to read. It is easy and pleasant to read, the book is average in size.

Feedback

In its simplest form, how it works.

A visitor comes to a cafe, chooses dishes, makes an order, gets food, eats, pays for it.

You can write the requirements that we want from the system at each stage.

The system should show the list of dishes, each dish has its composition, weight and price and be able to add to the basket. Why are we confident in these requirements? This is not described in the “standard” description of the requirements and this creates risks.

Performers who do not understand why this is necessary usually do not exactly what is needed. Artists who are not involved in the process of creating ideas are not involved in the result. Agile says, so let's focus first of all not on the system, but on people, consumers, their tasks and goals.

We make people, for empathy, we give them details and from the side of people we begin to tell stories.

Office employee Zakhar went for lunch and wants to have a quick snack. What does he want? The idea - 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 brought to him immediately, because he is used to drinking coffee before dinner.

And then there is the business (orgsonazh - a character representing the interests of some organization). Business wants to increase the average bill, increase the frequency of purchases, increase profits. The idea - and let's offer unusual dishes of some kind of cuisine. Another idea - and let's introduce breakfasts.

Ideas can and should be concretized, transformed and arranged 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 get the menu according 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: the connection in fine detail and the loss of conceptual understanding, plus the prioritization of the functional, creates a ragged picture because of inconsistency in goals.

The path of the author: We prioritize not the functional, but the result = what the user gets in the end.

The obvious non-obvious point: the prioritization session is not held by the whole team, because it’s ineffective, but by three people. The first is responsible for the business, the second for user experience and the third for implementation.

Highlight the minimum for solving one user problem (minimum viable solution) ,.

We detail the ideas of the first priority with the help of user stories, design sketches, restrictions and business rules on the user story map by telling and discussing with the team what people and stakeholders need at every step of the process. The remaining ideas are left unparsed, in the backlog of possibilities.

The process is written in the form of cards from left to right, and the ideas on the cards under the steps of the process. Be sure to pass the entire history of the story must be pronounced together with the staff of the team for the emergence of mutual understanding.

Working this way creates the integrity of the correspondence to the processes.

Received ideas need to be verified. A non-team member puts on a person's hat and lives in the person’s head day, solving his task. It is possible that he does not see the groundwork, creating cards again, and the team discovers alternatives.

Then there is a specification for evaluation. For this, three people are enough. Responsible for user experience, the developer, tester with a favorite question: “What if ...”.

At each stage, the discussion is on the map of the processes of the user's history, which allows keeping in mind the user's task to create the integrity of understanding.

Do I need documentation according to the author? Yes, I need it. But as notes, allowing you to remember what was agreed. Involving a person from the outside again requires discussion.

The author does not delve into the topic of sufficiency of documentation, focusing on the need for discussion. (Yes, documentation is needed, no matter how it is claimed by people who are shallow in understanding of agile). Also, the study of only a part of the possibilities may lead to the need for a complete rework of the entire system. The author points to the risk of excessive study in the case when they did not guess the idea.

To remove risks, it is necessary to quickly receive feedback on the product being created to minimize damage to the creation of the “wrong” product. They sketched ideas - validated with the user, sketched interface prototypes - validated with the user, etc. (Separately, it is indicated a little how to validate prototypes of programs). The goals of software development, especially at the initial stage, are learning through getting quick feedback, respectively, the first product created is sketches that can prove or disprove a hypothesis. (The author relies on Eric Rice's “Startup on Lean Methodology”).

A story map helps to establish communication if the implementation is provided by several teams. What should be on the map? What you need to support the conversation. Not just a user story (who, what, why), but ideas, facts, interface sketches, etc.

By dividing the cards on the history map into several horizontal lines, it is possible to divide the work into releases - select the very minimum, the functional buildup layer and bows.

We pronounce the stories on the process map.

A staff member came to lunch.

What does he want? Service speeds. To have his dinner waiting for him on the table or at least on a tray. Opa - missed step: the employee wanted to eat. He logged in and chose a business lunch option. He saw the calorie and nutritional value in order to follow a diet and not get fat. He saw the pictures of the dish to decide whether he would eat in this place or not.

Then he will go to get lunch and dinner? Or maybe he will get lunch at the office? Then the process step is the choice of the place of food. He wants to see the time when he will be delivered and how much it will cost to choose where to spend the time and effort - to go down or to work. He wants to see the cafe busy so as not to hustle in the lines.

Next, the employee came to the cafe. He wants to see his tray, to take it and immediately go to dinner. Cafe wants to take money to earn on service. The employee wants to lose a minimum of time in the calculations with the cafe, so as not to waste precious time without benefit. How to do it? Pay in advance or vice versa after servicing remotely. Or pay at the time with a kiosk. What is the most important thing from this? How many people are willing to pay for a lunch card? How many people will entrust the storage of a card number for repeated payments for this cafeteria? Without field research it is unclear whether testing is needed.

At each step of the process, you need to somehow provide the functionality, for this you need to take some person as a basis and choose what is more important to him (that same trio of electors). Gone history to the end = made a viable solution.

Next comes the detail. The client wants to see the cafe busy so as not to hustle in the queues. What exactly does he want?

Watch the forecast of how many people will be in 15 minutes, when he comes there

Watch average cafe service time and its dynamics for half an hour ahead

View the situation and the dynamics of employment tables

But what if the forecasting system gives an incomprehensible result or stops working?

Watch through the video queue at the cafe, as well as the employment of tables. Hmm, why not do it first?

The author points to a small exercise for practicing the practice: try to imagine what you are doing in the morning after waking up. One card = one action. Integrate cards (instead of grinding coffee - drink a refreshing drink) to remove individual details, taking into focus not the method of realization, but the goal.

For whom this book is for IT analysts and project managers. Be sure to 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 you did in the first, in the third - correct what was done in the first and second.

Cook stories like cakes - not by writing out a recipe for making, but by finding out who, for what reason, how many people have a cake. If you break the implementation, it is not for the manufacture of cakes, cream, etc., but for the manufacture of small ready-made cakes.

Software development is like making a movie when you need to carefully develop and lick the script, organize the stage, the actors, etc., before filming.

Resources will always be missed.

20% of efforts give a tangible result, 60% give it is unclear what, 20% of efforts go to harm - that is why it is important to focus on learning and not despair in case of a negative result.

Communicate with the user directly, feel in his skin. Focus on some issues.

Detailing and studying the history for evaluation is the most dreary part of the scrum, make the discussions stand in aquarium mode (3-4 people are discussing at the blackboard, if someone wants to participate, he replaces someone).