How to plan a two week sprint

Sometimes young development teams cover a mess.

This happens at the moment when they have not yet fully understood what the Ajile is; The project and product argue which of them is who, and the tasks each leads on its own. Or everyone already knows everything, but it is impossible to plan sprints - the tasks are not worked out, the demo and the retro run irregularly.

We also had a similar story, but we found our way.

This is a story from the team of your Yandex.Cashbox personal account, and detailed instructions for those who want to improve their planning.

How was it

The team of the Yandex.Cash department is responsible for the convenience of connecting new merchants to the Cashier and doing billing services. By the standards of Yandex, the team is young - 4 out of 6 developers work half a year or less, and I, the project manager, came to the team 3 months ago.

On the first day of the new sprint, the team gathered together with the product owner (hereinafter - PO) and planned a sprint for about two hours. This approach has obvious disadvantages:

1. Low study requirements. PO did not have enough time to answer all the questions. We either took such tasks in the sprint, or asked the analysts to evaluate the task and put it off until the start of the next sprint.
2. There were situations in which stakeholders were remembered when the sprint was in full swing and we urgently needed some kind of refinement or decisions from adjacent teams.
3. Lack of risk management.

With their consideration, the requirements for a new process have appeared:

1. Requirements for the tasks should be worked out by the product owner and all interested parties.
2. Implemented dod (definition of done is a set of criteria that allow you to understand whether what was the purpose of the development) for each activity. Began to identify interested parties, so that a week before the start of the new sprint to inform them about the progress of work and collect feedback.
3. Minimum meetings to focus on the current sprint. Limited to two meetings in two weeks for an hour each.
4. They began to conduct regular internal training on the product in a team, as today one of the key risks is a lack of knowledge about the product.

New concepts

We have introduced new containers (lists) of commands:

The priority of tasks in all lists except the first one is determined by PO.

If there are tasks in the sprint, the team member can take on the tasks from “Estimated” and will understand exactly what they are fully ready for work - take it and do it.

First week

By clicking - the full version.

Monday

The product owner moves the activity from the “Task List” container to “Grooming”, prioritizes and describes the Definition of Done as clearly as possible.

PM checks the activity in the “Grooming” container according to the checklist:

1. Are mockups needed for new activities and, if so, are they?
2. Have all activities entered the most important project?
3. Are connections between tasks indicated?

If something is wrong, PM communicates with the PO for details and notifies the command that the “Grooming” list is updated.

Example:

1. Take the task "Letters about bills at night are sent with a delay." It was added by the tester to the end of the “Grooming” list.
2. PO picked up this task in the list.
3. PM checked that the PO activity on the container side was carried out and notified the team.

Tuesday

The team gets acquainted with new activities and writes comments, questions and makes suggestions. PO automatically receives all new comments (we use Jira, so this is easy to do), and he has time to prepare answers by tomorrow.

Team member clarified whether the task is relevant. It turned out that the task is relevant, the tester found the cause of the problem and reported it. However, from the point of view of business logic, the question remains open.

Wednesday

We hold a meeting with the PO, which answers the questions of the team. The purpose of the meeting: fix DoD. Following the meeting, some of the activities will be transferred to the “Defined” container, and some - immediately to the “Estimated”, if it is immediately obvious how long this activity will take. We define dependencies and interested parties.

The dialogue between PM and PO, following which it became clear what needs to be done. Usually this dialogue is not fixed, but it is precisely for this activity that the PO was not available during the meeting, therefore the communication was recorded in writing.

Thursday

PM sends to interested parties a list of upcoming activities from the “Estimated” and “Defined” list with a request to look and give their comments.

Friday

PM answers stakeholder questions, inviting a team or a PO if necessary.

The task, which we show as an example, did not receive any comments, but in general it looks like this:

Feedback can come through the messenger.

The results of the first week are activities for which it is precisely clear what should be done (dod is determined), taking into account the wishes of the interested parties.

Second week

Monday

The team independently assesses the activities in the “Defined” list and decomposes the activities in the “Estimated” list. The PO is not involved here because it is responsible for setting the tasks on the part of the business and it is not its responsibility to assess how any of the planned has been done.

Tuesday

There is a second meeting with the PO, at which the team can clarify the details and communicate their estimates. The PO may report new introductory data that might have occurred during the past week, as well as clarify why it is such assessments for activities, and not less.

Wednesday

There is a demo for the current sprint. As a result of the demo, new activities are usually formed, some of which must be completed before the end of the week, and the rest - in the next sprint. The purpose of the demo is to collect feedback. The team presents the result of their work and receives early feedback on the work of the new functionality.

The demo is internal and external .

The internal demo is intended for the PO, where he assesses whether the team has achieved the result he expected, or if some improvements are needed. It is conducted by the tester on a test environment.

External demo is intended for interested parties. Occurs after the calculation of the new functionality "for battle", leads it PO.

After the demo new activities are added to the backlog and, depending on their priority and assessment, can be added to the current sprint. We specifically hold a demo in the middle of the second week to have time to finalize until the end of the sprint.

Thursday

The PO prioritizes the “Defined” lists (if the activities are completed earlier than the expected deadline during the sprint, then new activities can be taken from this list) and “Estimated” (the activities from this list are transferred to the new sprint).

Friday

A sprint planning takes place, in which the PM and PO development team is involved.

There is a retro scene where we discuss how we worked in the current sprint and whether we were well prepared for the following: we exchange opinions, is everything clear for the upcoming sprint, did we have a reserve in the resource for repairing unforeseen bugs.

A risk management meeting takes place. At the moment, we are devoting this time to studying the product, since its excellent understanding significantly reduces the risks. PM, together with the testers during the week, allocates time to study the product and shares the result with the team. Representatives of divisions are invited to the meeting to complete the picture.

Every second Friday is the completion of not only the working week, but also a sprint. This is a day of communication and feedback. Thus, Monday of the new work week begins with clear and evaluated tasks, which is also logical and comfortable for the team.

Conclusions and Next Steps

Through this process, we managed to establish a qualitative interaction between the PO and the team, conflicts and misunderstandings are a thing of the past. The climate in the team improved, and a sense of well-coordinated rhythmic work appeared. Of course, there are still a lot of problems, but there were a lot less emergency and unforeseen situations in which the team or PM had to save the project.

Like all living things, our process requires updating from time to time. Now we see that it should be improved in the following directions:

1. Bugs. Work with bugs, too, must be planned. Appearing bugs, we can not carry out the planning process for the sprint, it requires more operational work. We are thinking about how to do this.
2. We want to make a table of typical risks in order to take them into account and reduce the likelihood of errors during the implementation of the sprint.
3. When planning a sprint, we want to build on the sprint goal in order to keep the focus of work. The team is young, so there are difficulties with this.

We hope that our experience will help your team. We are ready to discuss our approach in the comments, answer questions or give advice.