We treat building new software or product as a project, which we divide into tasks and periods in which a given task needs to be performed. Various project management methodologies have their pros and cons. In this article, you'll learn what Scrum is, what the management approach is, why you should use it and how to get started.

Scrum is eagerly used to create IT products, but successfully goes beyond the IT world and is used to introduce new services or marketing campaigns. Its main advantage is simplicity in use and efficiency in bringing the project to the end. Scrum is based on product delivery in short cycles (sprints) that are time-limited (1-4 weeks). Thanks to this, we obtain a guarantee that all interested parties (the client and the team working on the topic) know where the project is, what the next step will be and what to expect after the finished sprint. An additional advantage is the necessity to set a definition of the product's operation (Definition of Done - DoD), which eliminates the risk of misunderstandings (Strange, it works for me ...).

Roles in Scrum

Development Team – responsible for providing a working product. It often consists of people complementing each other competencies (eg programming, testing, analysis), but they do not have formal roles (tester, analyst, programmer). There are also no leaders or managers. The team is small (3-9 people), it independently estimates and measures progress.

Product Owner (PO) - has a vision of the product, which transforms into a segregated list of expectations (Product Register - Product Backlog) and focuses on ROI (maximizing profit from investment). He constantly analyzes the market and reacts to changes or emerging new needs for the product.

Scrum Master (SM) - understands and explains the principles of Scrum and makes sure that they are applied. He supports the team in the use of Scrum by observing and identifying the causes of problems in the team with Scrum. He does not impose solutions, he asks questions that help the team find their own.

Scrum process

1. Product Owner arranges a list of needs in the Product Register (Product Register) in the order from the most important to the least important based on the needs of stakeholders and the market situation.

2. PO manages a meeting called Sprint Planning, during which the team determines what and how it will deliver from the Product Backlog. The team is building Sprint Backlog.

3. The team meets every day for 15 minutes to synchronize their activities. We call it Daily Scrum.

4. After the time set for Sprint, the summary meeting (Sprint Review) takes place, where the Team together with the PO presents what was created during the Sprint and get feedback on their work.

5. Team and PO during the Sprint Retrospective The team determines how it can work more effectively.

6. After a certain number of sprints, the customer receives a ready and efficient product.

Scrum foundations

The effectiveness of working in Scrum is based on three pillars. The most important is Transparency. It allows you to get an idea of what is happening in the project and gain confidence in the declared tasks (eg if the team declares that the QR code scanning function works, it means that it is, because without this you can not go further according to Spring Backlog and Product Backlog). Also, the reality of the implementation of the plans and requirements posed by the PO has a chance to be verified on an ongoing basis. If something is wrong, it will reveal a delay in implementing Sprint. This knowledge allows Inspect, that is, drawing conclusions from mistakes made and implementing corrective actions. This in turn forces Adapt - reorganizing plans and adapting the process or product to reality (eg changing the scope, technology or method).

The principles of working at Scrum are easy and clear. Unfortunately, like any novelty in a team, it can be resentful at first stumble. It should be remembered that practice makes perfect, and after finishing the project in Scrum, compile it with a similar method implemented in a different methodology, with particular emphasis on communication with the client and his expectations regarding the product and reality after project delivery.