Get best of the week

Hourly planning and other scrum event optimization

image
Pure Scrum is like a unicorn at a music festival: it seems to exist, everyone is talking about it, only no one can show it to you. It also happened in our team, we’ll talk about this. And more specifically, about how we reduced the time for meetings and did not lose benefit from them.

Of course, the Internet is full of articles about who and how this scrum cultivated in themselves, what happened and what didn’t. I do not pretend to be unique and have not read everything, because there are much more writers of such articles than I have free time. However, I want to tell how we in the Android development team built (and are still building) the process, practically without wasting time on meetings and discussions. It happened just because my time (I’m PO) and the time of the team are very limited, and I strive to do everything so as not to engage in processes for the sake of processes and at the same time to maintain high level performance and transparency.

I will give a little idea of ​​myself, so that the reader begins to develop a portrait of the person from whose person the story is being narrated.

I am the product manager for the Android team at Wrike. In addition to this, I had the honorable role of a scrum master.

We are a satellite app, and most of our customers work in the office and use the web version of the product. We have about 3 key releases per quarter, but a lot of time has to be devoted to supporting improvements from the web version. Due to the active development of the web, we will be released once every two weeks. The function of the application is not to lose touch with the team and monitor work processes. You can configure the environment only in the web version. Product development strategy is to increase the audience and its activity on mobile devices. Our team consists of five Android developers, two QA, one UX designer, one product manager. All the guys are very skilled.

Now that the reader has some idea of ​​the team, I will move on to the essence of the article - the processes. Today we will talk about such scrum elements as: PBR, Retro, Planning, Daily. My main goal as a scrum master is to use the value of these meetings and at the same time spend a minimum of time on them. Besides the fact that it is just logical in terms of resource optimization, we have one more limitation: our team must support the changes of twenty product teams. We do not support all changes, but those that affect existing functionality require our participation. In the article I will tell you more about how much time we devote to each of these four rituals and what benefits such a time frame brings.

PBR


I looked at the Internet for such a definition : “PBR (Product Backlog Refinement) is the process of adding parts, ratings and order to items in the list of backlogs”. From my own experience I know that at such an event the whole team is often present to see the task in advance, highlight unobvious moments. But such a meeting requires a lot of time, but our team does not have it, because a lot of changes are coming from the web version. Therefore, we changed the format of the meeting.

As practice has shown, there is a list of tasks that can be very complex or uncharacteristic, at first glance, for the product. Before researching such problems, I gather everyone and tell the essence of what is happening - this is called Forum. This happens extremely rarely, however, it unites the team decently and fuels interest in the task, and involvement in the product is addictive. And this involvement is growing precisely because of its irregularity. Such a meeting becomes something special, non-routine and therefore significant.

The analysis of the work is as follows: each task (story) is planned for one person (let's call him “champion”), and he conducts a study of what exactly needs to be done on it. Adds a description, clarifies with the UX designer how some points should work if this is not enough in the dock, consults the backend and writes a detailed plan. In fact, it turns out something like Spike .

This approach has proven itself for the following reasons:

  • A long time working on a task allows us to better understand its essence. A deep understanding of the problem leads to the fact that the champion can find the mistakes made during the design. And now I am not only about the code, but also about the idea itself. A kind of check of the decision for organicity.
  • For myself, I noted that the motivation of the team is growing (there are no growth graphs of happiness, sorry) and the desire to bring the task to production.
  • If the champion’s motivation is high, and he understands the essence of the problem, then he gives birth to proposals that allow to reduce the development cost, the backlog of technical tasks is filled, offers for UX appear. The latter can save a lot of programmer time.

I want to pay special attention to the time spent on such research. Challenges require deep diving, especially in the case of legacy. Here, in my opinion, there are 3 main strategies:

  1. “We'll figure it out on the spot” - usually the end of such a task is not visible until it is almost complete.
  2. « » — : « , ». , .
  3. « » — , , .

In case the tasks are non-trivial, the research often goes in parallel with the development. Normal code discovery takes no more than a day and allows you to build a completely accurate development plan. I would say that of all tasks, about 10% are subject to research, the rest can be taken into work without this process. Our recipe for performance is strong developers and the rule is that 20% of the resources are allocated to technical tasks. The team knows better how and where to direct efforts to keep the code in a healthy state. For me, this is exactly the tool that allows you to move quickly with product tasks, keep developers happy, plan clearly and be on time. It develops an engineering culture and supports the motivation of the guys on the team.

Retro


Here I will not brag, just say that the team has a rule: together with the problem, offer a solution. The guys in the team are responsible, they want to work well and not be distracted by unpleasant trifles, so they are interested in the processes being clear and reliable.

Let me give an example of the problem (problem) that faced us at Retro - we forget to add analytics. It may seem that it concerns PM rather than developers, but, as I said, the guys on the team are motivated and want to do their job well. Due to the limited analytics resource, this process is ideally impossible to conduct, because right on retro we built a specific process and shared responsibilities between team members so that everyone brings their own benefit at a certain stage. Also an important note: if in an hour we did not have time to figure out how to solve the problem, we agree to try the proposed ideas and adjust them along the way.

But there are also borderline cases when professional goals diverge somewhat, and rough spots may appear between team members, in other words, engineers are more focused on the technical part, PM on the product, and the designer on convenience and graphics. But since our main common goal is to create a good product, we are not shy about discussing issues at the intersection of interests of team members. And here it is worth saying that it is customary for us to be open and honest. If someone in the team is embarrassed to express their point of view, then there is a high probability that the team has an inequality or there are hidden conflicts. Only equality in the system allows you to be open. If you are interested in how we managed to do this, let me know in the comments, but for now, let's go further.

Planning


My favorite part of scrum. I like it for two reasons:

  1. it's fun;
  2. it practically does not require my participation.

The process looks like this: there is a list of tasks that I define for the sprint. Each team member together with others decides at what point and what is better to start doing, what will be the acceptance criteria for the task. Team members themselves set the dependencies between UX, DEV and QA. And it’s fun precisely because the guys agree themselves, plan their priority tasks in a comfortable order for them. They discuss, joke, they act as a team, they are united at this moment. Depending on their plans / mood, they understand what and when they want to do, and the time and dependencies are set on this. It turns out something like Workload - planning is not based on tasks, but on people.

image
At first glance it may seem like a mess, but due to the fact that the team itself plans, it is well versed in what is happening and promptly makes changes

Daily


First of all, this is about synchronization, but I want to emphasize separately my role as a product manager in this event. I have already said that equality is important in a team. The climate should be such that the guys feel like a team, not individual contributors. Therefore, as a product manager, I tell the company news, as well as what I was doing, what I recognized and what awaited me. I have no secrets in front of the team, although exceptions are extremely rare: some things are asked to be kept until the official announcement. But such announcements are just something out of the ordinary.

Total


Spike for 1 day + rare meetings in the Forum format for introducing children to unusual tasks give a good understanding of what kind of work we have to do. Planning takes only an hour and takes place in a free form, all people agree perfectly on what they need to do. Retro always takes place in one format, but it is very productive, and little things in the processes are sharpened regularly. And the openness of the product manager in the daily team forms equality and trust in the team.

For me, ultimately, only three indicators make sense: the level of team satisfaction so that the guys do not burn out, the quality of the product and the speed of the tasks.

And these indicators in our team are quite high:

  • Quality: 2-3 bugs after the release (and we have large releases);
  • Speed: our team of five developers, two QA and one UX supports the changes that twenty web teams create;
  • Satisfaction: in the five years of my work at Wrike, one developer and one QA left the company.

Icing on the cake


A bit of math. For a two-week sprint it turns out:

  • 10 Daily for 15 minutes;
  • ± 2 Forum per hour;
  • Planning 1 hour;
  • Retro 1 hour.

Total: 4h 30min ± 2 hours out of 80 hours in a two-week sprint.

It’s clear that this number should be multiplied by the number of people in the team to understand how many person hours the event scrum cost you. My indicator is 5.6% ± 2.5% with a team size of 9 people. The larger the team, the higher this value will grow. But let's not forget that the scrum team has the recommended sizes, which means that the indicator of time spent on team events also has a reasonable limit.

In general, for now. It will be ideal if you share the figures: how much time do you have in the event scrum. Well, to make the article more valuable, let's discuss the benefits and harms that, in your opinion, such optimizations can bring.

More articles:


All Articles