Training "Requirements Management in Agile Projects"

Recently, during the "course of the young fighter Coach ”, which assumes that all employees of all the ScrumTrek trainings pass through, I attended the Training Requirements Management in Agile-projects . Below I will talk about the impressions that remained after the training.

First, a little about the training itself: it was held in Moscow in the office of the ScrumTrek company, lasted two full days and was dedicated. Daria Ryzhkova conducted the training - Agile Coach with extensive experience as a Product Owner in food software companies.
The first thing that surprised me and pleased me: about 50% of the participants came from various cities of Russia. There were people from Izhevsk, from the northern capital and even from the Urals. It means that software development in Russia is not concentrated only in Moscow.
The second thing I liked was the game with which the training begins. The game is very simple, but clearly illustrates that TK, e-mail, etc. - this is a “spoiled phone”, which has a bad effect on the results of the project.
Training participants are divided into several teams, in each one person is selected who plays the role of a developer. The remaining few people play the role of analysts, who must convey to the developer the requirements for the product. Our product in the game was a simple pattern of geometric shapes, which the developer must portray. It would seem, what is easier? But analysts are exposed to a restriction: they have to formalize the task in the form of a written statement of work, transfer it to the developer, and all further communication with the developer must take place in writing. All according to the "best" corporate practices ...
As a result, of course, we get something remotely similar to what the customer wanted. How familiar, isn't it?

The upper figure is the customer's vision, the lower figure is the result of the execution of the TZ.

At the second stage of the game, analysts and the developer are already allowed to communicate verbally. The final result in this situation, as you guessed, is significantly different from the previous one.

The top drawing is the customer’s vision, the bottom drawing is the result of the execution.

After the game, immersing the participants in the main issues, the coach and the participants proceed to the analysis of the basic principles of requirements management in Agile projects. Briefly they can be collected in the following points:

1. Development from general to specific (from general vision to specific features).
2. Incremental vs iterative (each stage of implementation provides an increase in value for the client / customer).
3. Iterative implementation (implementation / delivery is carried out in short iterations).
4. Communication face to face.
5. Passing the business context to the team is more important than perfectly written requirements.
   Further, the focus of training is shifted to the consideration of various types and methods of communication that can be used in a team, their effectiveness, time spent on organizing a particular method.
   
   

The prologue perfectly illustrates one of Agile's values: “People and interaction are more important than processes and tools.” Next, the trainer proceeds to review the tools and approaches that are used in Agile to identify, fix and manage requirements.
The program of the first day is rich, it includes: a brief insight into the Scrum Framework, the structure and properties of the product backlog, and methods for evaluating backlog, and the principles of working with stakeholders.
I somehow especially remember the method of bulk estimation. It allows you to quickly assess backlog and systematize the levels of planning for product development.

The second day of the training was devoted to practical techniques: we formed Vision and product models using Lean Canvas, built a user's portrait using the Pragmatic Persons approach, decomposed user stories, and dismantled user experience with the product into user stories using Story Mapping and so on.
All of these techniques went in conjunction with building a product model, on which teams worked on the second day. As a result, our team proudly presented the product model “Bystronian”.

In general, the training was productive for me. I would recommend to pass it not only to those who are planning to become a Product Owner, but to each member of an existing or only planned Agile team. In Agile projects, the entire team is involved in working with the requirements, from the very beginning of the project.
What I would advise to the organizers of the training: add practices and examples, how to smoothly move from traditional approaches in working with the requirements for their flexible management.