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 Yandex.Cash team’s personal account 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 the sprint for about two hours. This approach has obvious disadvantages:

Low study requirements. PO did not have enough time to answer all the questions. We either took such tasks in the sprint, or asked analysts to evaluate the task and postponed its execution until the beginning of the next sprint.
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.
Lack of risk management.

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

Requirements for the tasks should be worked out by the product owner and all interested parties.
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.
Minimum meetings to focus on the current sprint. Limited to two meetings in two weeks for an hour each.
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 the tasks end in a sprint - a team member can take on the tasks from “Estimated” and will understand exactly what they are completely 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:

Are mockups needed for new activities and, if so, are they?
Have all activities entered the most important project?
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:

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.
PO picked up this task in the list.
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.

A 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: to fix the DoD. Following the meeting, some of the activities will be transferred to the “Defined” container, and some - immediately to “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 was 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 clear what to do (dod determined), taking into account the wishes of the interested parties.