Scrum for Beginners - Complete Guide 2025

Lets discuss why waterfall approach may not work properly sometimes.

Not all project fit Agile approach. Lets find out which projects fits Agile properly.

10 000  feet Scrum overview before we dive into details of Scrum

What are the roles in Scrum and what these roles are responsible for.

What are some other roles that may be involved into Scrum project and how it works together

Scrum ceremonies or events described step by step - when to hold meeting, who joins particular meeting, what time limits are recommended. what techniques may be applied

Scrum Retrospective - the way to improve your team efficiency. But how?

Lets talk more about retrospective because I think this is the most confusing part of the scrum. You probably can imagine how to run sprint demo, sprint planning, daily scrum but retro is confusing.

If done right, retro can highlight opportunities for change, generate meaningful process improvements, and ultimately move the team in the right direction. If done poorly, a sprint retrospective can turn into a blame game.

Artifacts or objects of the Scrum - what they include and how to work with it.

We have looked at roles, Scrum events. Now let's take a look at Scrum artifacts.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Simply it is just a to do list for a team with priorities.

The Product Backlog is the main artifact of Scrum, it contains all the requirements for the product in a prioritized form. In a prioritized form means the most important elements are at the top, the least important are at the bottom. Responsible for filling is Product Owner together with the scrum team. This is dynamic document that is constantly changing, some elements are added, some elements are removed or changed.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

A sprint backlog is a piece of a large product backlog that a team takes into work for 1 sprint. All elements of the sprint backlog must have estimated to go through a full cycle of creation, that is, design, development, testing and deployment on a production server. This is your to do list for 1 sprint that you discuss with product owner on planning session and commit you will complete by the end of the sprint. Sometime for some reason you may not complete all sprint backlog element and that’s OK but most of the time you should complete all of them or something wrong with you planning approach.

Increment - everything that the team managed to complete during the sprint and everything that is ready to be delivered to the customer or user as a result of the sprint.

A work cannot be considered part of Increment if it is not ready for delivery in the full sense of the word - if the documentation is not completed or testing is not carried out.

Now you probably have a question - how to write a Scrum Backlog? What does it look like?

This is a template in which it is quite easy and simple to capture business requirements. The template looks like this. As a <persona or role>, I want to <state what is required>, So that <why you need it, state a reason for the feature>

Acceptance criteria is what really good teams do in order to have clear objectives and satisfied customer. Every Scrum User Story should have acceptance criteria that can be tested and demonstrated. It is desirable to have binary parameters, that is, PASS or NOT PASS. There should be several such parameters for each User Story. About 3-5 is recommended.

Definition of Done, Working Agreement and other important points of Scrum

How to estimate users stories or tasks in Scrum? How to compare? What techniques to use?

Lets talk about why it is important. First of all estimation provide you with estimated duration for the tasks of feature or project to be completed. Then you can use it for planning and moving forward.

The second important thing is that estimating helps to dive into clarification. When product owner states a requirement in order to estimate it you will have to ask quite a lot of questions to make sure that you understand everything clearly and can make precise estimate on complexity of the feature and what is more on duration. This is a very important part of the Scrum

Any project must be monitored somehow. But how to do it with Scrum project?

Now let's talk about estimating in Agile. How tasks are estimated. But before that, let's remember how tasks are evaluated in the waterfall management model. There is usually a task there, it is given to the developer or another team member and he responds after some time, task A will take me 5 days, and task B will take 11 days. Thus, the project schedule is built. Each change in task scoring can have a big impact on the project as a whole, especially if the task is on the project's critical path.

In Agile, estimation is relative. That is, we compare the sizes of tasks with each other.