Hello! My name is Anatoly Savchenko, I am a developer and concurrently a Scrum Master in the team of the AutoTech service. As you may have guessed, we are working in Scrum. Every two weeks we conduct a sprint review - a meeting where the team and stakeholders discuss what has been done. Based on this information, the team can draw conclusions about whether development is moving in the right direction, what improvements are still needed, etc. Recently, we have gained valuable new experience in holding this important meeting. I want to tell you about him.

Feedback Tools

Of course, a sprint review is not the only feedback channel: we have a UX laboratory, we process reviews in mobile application stores, support calls, reviews on various Internet resources, we conduct user surveys on the site and more.

This is for private users.

In addition to them, we work with business partners to whom we provide additional functionality and work tools. We have a closer interaction with them. Our managers are always in touch with them (mail, phone), there are chats in instant messengers, which are members of the development team. Thus, we become closer to our business users: we know them better, understand their needs, hear them and feel their pain or joy.

And these are all wonderful and necessary communication channels. But they give information after the release. In addition, in this case, the development team is still quite far from users. That is why sprint reviews can be most beneficial to a team, product, and ultimately to users.

Sprint review - as it was before

Our meetings were generally held at a good level: we received prompt and high-quality comments from our stakeholders (that is, internal customers - managers) and other colleagues from Avito. A rather chamber situation was created, but at some point we began to miss the fullness of the feedback. We wanted to change something. And our agile trainer Levon Goncharov from AgileVerse led us to the idea of ​​inviting external users - our business partners - directly to the meeting.

Levon Goncharov, co-founder AgileVerse: “I met the guys when they decided to improve their processes. They understood that something was going wrong, and were looking for an answer. During the diagnosis, each team member somehow spoke of the need to understand "how the user lives." It influenced someone from the point of view of motivation, someone needed to understand how to develop the project architecturally. This, in principle, is a fairly common problem of scrum teams - turning a sprint review into a meeting, where they tell what has been done and think not as creators, but as performers. To prevent this, you need to think about this.



No. 1 When you develop a product, do you think more about features or user problems?

№2 Do you know how your user lives and why should he use your product?

No. 3 Do you often communicate with those who use your product?

I advised the team to discuss these issues and change the format of the sprint review.

The case of chatting with users appeared quite quickly. By the end of the sprint, we planned to release a new tool for partners from the assembly line that no one had seen before. And we decided "on hot" to collect feedback on a product that has not yet been released.

Training

To begin with, Levon and my colleagues gathered expectations from a new meeting, after which we planned the agenda and prepared all the necessary materials.

I can say that about one preparation alone one could write a whole post. It allowed us to create an integral picture of the meeting and take absolutely everything into account (of course, we did not take into account everything, because it is impossible, but we took into account this).

First, we painted the goal and image of the result on a flipchart. We registered points for the general plan of the meeting. Detailing the filling of each stage.

We registered the timings of all stages (and rewrote them several times). We determined the necessary materials for each stage and wrote down what you need to remember to take to the meeting.

In short, this is what we got.

goal

1. Speak the team focus for the quarter
2. Understand how the updated user account (LCP) meets the needs
3. Show teasers and formulate a plan for 1-2 sprints

Plan

1. Opening (5 minutes)
   
   a. Agenda
   
   b. We tell you how to give feedback
   
   c. Meeting the team
2. Common part (15 minutes)
   
   a. What did you do?
   
   b. Future plans (focus on the quarter)
   
   c. Q&A
3. Demo (15 minutes)
   
   a. Discuss
   
   b. Teasers
4. LCP Dialogue (10 minutes)
   
   a. What did you find? (what is so, what is not)
   
   b. When we finish (approximate sprint)
   
   c. What to replace? (talking about the life of the user)
5. Gathering feedback on the review format (5 minutes)

Result Image

1. Quarterly feedback
2. List of improvements on the paintwork
3. Discuss the most severe pains of the user, write down the rest
4. Discuss a common understanding of teasers, plans for 1-2 sprints
5. Feedback on the format of the review from the participants

Levon Goncharov, co-founder AgileVerse: “When we fill out a sample meeting agenda, we write out everything that can happen on it and in what ways we can manage it. We assumed that users would begin to talk about completely common pains and we introduced this into the sprint review design. But in the process of preparation, it became clear that there was not enough space for this. So we got useful information before the meeting that we won’t be able to touch on common topics. ”

How did everything go

The main idea was to give our users a live experience of contact with the product and get maximum feedback. Here's what we came up with: we put each of our guests behind a laptop with a product, next to which there were always two team members. The role of one is to talk about the product and answer questions, and the second is to record as much as possible everything that happens, then to process it together with the owner of the product.

Well, it turned out a little more than two team members for each guest

The discussion turned out to be saturated, and we even extended the time for displaying the product. As a result, we not only received a lot of useful comments, but also learned how the work of our partner was built from the inside. This will help us in planning further work on the product.

It looked like the first version of the product

We wanted to place the maximum of useful information on one page, but for users the interface turned out to be overloaded. In addition, some of the information was simply incomprehensible.

We recorded the comments and wishes of our guests, noted the most important and priority, and immediately discussed with partners what and when we are going to implement it.

Feedback has helped us rethink how we can conveniently and clearly present information to the user. At the time of writing, the highest-priority edits have already been made, which significantly transformed the original version.

Product Version After Edits

Thanks to early feedback, we were able to avoid a situation where we gave our users a raw product that needed to be edited on the go.

As a team, we have gained very valuable experience. This is what my colleagues say.

Vadim Ivanov, CEO of Autoteks: “I consider this kind of feedback collection to be very useful and necessary practice, which, in a good way, had to be implemented much earlier: it’s one thing to watch / listen to sprint reviews in the cozy atmosphere of positive-minded colleagues, it’s quite another to see right away a lively user response to the work done. The opinion of business users is doubly useful, as they often know more precisely their needs and problems. Even the first attempt turned out to be successful, the whole team was very enthusiastic and involved in the process, managed to collect valuable comments that were immediately taken into work even before the first release of the new functionality and, as a result, made a much more prepared product for partners. And the extra labor costs for preparing the event more than paid off. I recommend everyone to implement such methods at home and not be afraid to experiment. ”

Mansur Ahmadi, QA Autotech: “In the engineer’s head, the image of the end user and his UX often diverge from the real picture of the world, which in turn can lead to not the most suitable solutions. At the last meeting, this was quite clear when our guest outlined his vision of the product. That vision, which would give him more happiness. That vision that we should focus on. In my opinion, precisely such meetings help to come to him faster. ”

Andrey Tumkin, product owner Autoteks: “The first thing that may come to mind before inviting real users to a demo is why? At the early stages, we revealed their pains, and after the release we collect feedback and make corrections. But not so simple.

Firstly, you will lose time and money, instead of immediately solving user problems. Secondly, even CusDev conducted prior to development will not be able to identify all the problems that open up in a real product. Thirdly, no other process will give such a team involvement in the product. "

Conclusion

Meeting with users is not just a tool for improving and getting feedback, it is a real building of relationships with those for whom you are making a product, and awareness of the importance of this work.

Our team was very inspired by the experience gained, so we plan to introduce such a practice on a regular basis - once a month or two. I wish you to hold a similar meeting and see what comes of it. Good luck