Project management in SCRUM

How it works?

In practice, this means that the entire process is constantly optimized and adapted to the needs of the team and the product throughout the entire period of work on the project. Responsibility for managing product development is spread between the product owner (PO) and the design team. PO is the person responsible for making decisions related to the direction of product development and has a holistic “vision” of what the product is to become. Task management is based on the Kanban board (in conjunction with the sprint functionality called the SCRUM board). Each participant in the process can add tasks to the backlog, but the OP is responsible for setting priorities. The project team is responsible for “transforming” the PO’s ideas into specific tasks and planning their implementation.

Course of the cycle

The process is divided into iterations (sprints). As part of one sprint lasting approximately 2 weeks, the project team implements and tests the previously planned part of the functionality.

Sprint begins with “planning”, where the team discusses and prepares the tasks that have been previously groomed and set up by the PO at the top of the backlog. Thereafter, the difficulty of these tasks is estimated and they are given points according to the difficulty. With relatively constant team composition and working conditions, the number of points performed in each sprint is repeatable and allows the planning of future work. At the end of the planning meeting, tasks with a total number of points to be completed within one sprint are selected, and a new sprint begins.

In the middle of the sprint, grooming occurs. This is a meeting at which the OP presents the team with further expectations and ideas, while the project team analyzes them, breaks them down into smaller tasks, and presents possible suggestions to the OP. When planning future tasks, the OP consults with analysts, users, UX, and graphic designers. Additional analyses (market research and data science) are often needed at this stage. Only after analyzing and formulating the so-called User Story will the PO publish those Stories in a backlog. The User Story should contain information on what the OP expects from a given task or group of tasks and on what criteria should be used to recognize whether the task is completed.

During the sprint, so called “Daily standup meeting” are held on a daily basis. At these meetings, each developer tells the rest of the team what he has been doing for the last day and possibly informs about any problems or blockades that impede his further work. Thanks to this exchange of current status, it is possible to catch potential conflicts between various tasks much faster and avoid the situation where the developer gets stuck on a problem and cannot make progress on it. The daily standup assumption is to be as short as possible, but fulfilling its role at the same time. The standing formula of the meeting encourages team to keep it short.

During the sprint, tasks are moved on the SCRUM board according to their current status. The choice of columns usually corresponds to the work system of the companies or the team and is associated with the version-control system and the frequency of releases. For us it is as follows:

• To do – tasks waiting to be completed
• In progress – tasks in progress
• Code review – tasks waiting to be checked by another developer
• Prepared – tasks checked and accepted by developers
• Staged – tasks located on a staging instance and waiting for PO approval
• Accepted – tasks accepted by the PO
• Done – ready tasks located on the production instance

After the sprint, a retrospective takes place. This is a meeting dedicated to work optimization. The whole team discusses what has gone well in the last sprint and what needs improvement. We also often refer to the previous retrospective and check whether we have been able to implement all ideas to improve work. The problems discussed at the retrospective can be anything from development tools, through pressure, task difficulty, to communication problems (both between developers and the team and the PO).

Responsibilities of the SCRUM master

The person responsible for the proper conduct of the SCRUM process is the SCRUM master. This is often the most incomprehensible role in the team. The SCRUM master has no decision-making power. Decisions are made jointly by the team and the PO, while the role of the SCRUM master is to remove obstacles in the proper course of the process.

The duties of the SCRUM master include the following:

• Conducting SCRUM meetings, including planning, grooming, daily standup meeting, and retrospective
• Ensuring that tasks on the SCRUM board are regularly groomed by the team and prioritized by the PO
• Functioning as a link between the team and the PO; hence, it is often the SCRUM master who has a difficult role in translating the language of programmers into the business language, and vice versa. This is due to the fact that, in our company, the SCRUM master is a developer, hence a technical person. The general framework of the SCRUM master’s work does not require this.
• Stopping team from going off-topic and guarding the agenda at meetings
• Caring for the atmosphere in the team — mainly at meetings.
• Resolving conflicts if they arise.

Read also:

• Codest’s good practices for building software. Our approach to customer journey
• Codest’s good practice for building software: GitFlow
• Codest’s good practices for building software. How do we implement the requirement analysis?