Table of Contents
Scrum has already proved to be one of the most effective methodologies for managing a product development process. It helps teams set a workflow and make the work on a project as productive and efficient as possible.
We have a separate article explaining what Scrum is, the philosophy behind it and its main benefits for the development process. You can read it here.
Yet, if you didn’t hear much about this approach before, it might be quite challenging to figure out how Scrum works. This is because unlike more conventional project management methodologies (for example, Waterfall), Scrum has its own terminology and quite strict rules which have to be followed. But, actually, it is not complicated at all.
In this article, we’ll try to explain Scrum in simple words, so you can clearly understand all the nuts and bolts and appreciate its advantages yourself. Let’s start with exploring who is who in Scrum.
Scrum Team
All Scrum team members have their own roles with specific responsibilities. The main difference between a Scrum and traditional team is that the former has no team leader to make all the crucial decisions and solve all the problems. Instead, a Scrum team as a whole decides what is the best way to accomplish the tasks and overcome the challenges.
A Scrum team consists of a Product Owner, Development Team and Scrum Master. There are also stakeholders, i.e. people who have a specific interest in a product. Usually, these people are the clients whose need of a certain tech solution became a trigger for the commencement of a software development project. Stakeholders are not in a Scrum team but since they influence a product development process, they may take part in separate Scrum events if needed. In all other instances, stakeholders are represented by a Product Owner.
A Product Owner is a person who turns stakeholders’ needs into specific user stories, i.e. concrete features of a product. Since a Product Owner has a vision of a product, his or her main responsibility is to decide what has to be developed (so-called Product Backlog) by a Development Team and in what sequence. To perform this task, a Product Owner usually consults a Development Team, but, either way, he or she remains accountable.
As you may have already guessed, a Development Team is a team of software engineers who actually do the work. They are the only people who decide how to turn a user story into a product increment. In Scrum, a Development Team may not have less than three and more than nine members. As explained in Scrum Guide, this is an optimal number of team members that allows a team to complete a significant amount of work without too much coordination.
There is also a Scrum Master. Basically, this person is a facilitator that manages a process of cooperation and information exchange within the Scrum software development framework. In other words, he or she coaches a team by focusing on how to organize the work in the most efficient way.
So, how do all of them cooperate and how does Scrum actually work? Let’s talk about this in more details.
Defining a Product Backlog
According to Scrum Guide, a Product Backlog is an ordered list of the work to be done in order to create, maintain and sustain a product.
In traditional methodologies (e.g. Waterfall), all or at least most of the tasks are planned at the beginning so the scope of work is not usually subject to changes along the road. However, Scrum procedure for defining a Product Backlog is different. As the product development in Scrum is broken into relatively short iterations, a team has an opportunity to gradually accumulate knowledge about a product, so the decisions are made one at a time based on the information acquired from all previous iterations. Here’s how the process looks like.
Assessment and ordering the feature requests
Everything, of course, starts with ideas, and it’s a common situation that clients (or stakeholders) have lots of them. Naturally, not all the features they envisioned can be developed at once, so the first challenge is to prioritize the feature requests. As we have already mentioned, this is the responsibility of a Product Owner.
Having discussed the ideas with stakeholders, a Product Owner assesses them based on two criteria: value (i.e. are they critically important or just nice to have?) and size (i.e. how much time would it take to build each of them?).
After that, he or she determines the sequence of what should be built. For example, if a user story has a greater value, a Development Team should work on it first; if two user stories have the same value one is bigger, a Development Team should work on the one that is smaller, and so on.
Saying “No” to some features
In some instances, a Product Owner may define that it’s not expedient to build a particular feature due to budget limitations or some other reasons, so he or she may say “No” to some stakeholders’ requests.
Yet, a Product Owner is not a “bad policeman” who “kills” stakeholders’ dreams. On the contrary, he or she optimizes the work, so that stakeholders may receive the best product, or better to say a product with the best possible set of features, within the budget they have. For example, stakeholders would doubtedly be happy if development of an optional feature will “eat” all their money before the essential features are even built.
The above assessment process applies not only to the initial ideas but also to all further feature requests that a Product Owner receives during a software development process.
Collaboration with Development Team and stakeholders
It’s important to mention that a Product Owner does not work in isolation (in fact, no one does in Scrum), he or she communicates with stakeholders and a Development Team all the time. Stakeholders help a Product Owner define a value of user stories, while a Development Team consults him or her on the time needed to build each feature.
Of course, it’s not the exact science, so there might be a lot of guesses at first. Yet, with the release of each further increment, a Scrum Team accumulates more and more knowledge about a product and the assessments become more accurate.
Hence, defining a Product Backlog in Scrum is a continuous process. And although a Product Owner is a person who is ultimately responsible for deciding what goes in and what goes out, the whole Scrum Team along with stakeholders take part in performing this task. This is possible due to iteration and communication — two foundations the work in Scrum is based on. Iteration and communication are ensured by Scrum events, so let’s talk about them next.
Scrum events
A distinctive feature of Scrum is that it’s flexible, meaning that there is nothing engraved in stone and everything can be changed and adapted to new circumstances at any time. For this reason, effective and regular communication is essential for making the process work as it’s supposed to. Such communication occurs during Scrum events, the main purpose of which is to create a formal opportunity to inspect and adapt a product.
The key Scrum event (or how the authors of Scrum Guide call it “the heart of Scrum”) is a Sprint. It consists of other events such as Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective, as well as the development work.
Simply put, Sprint is an iteration with a duration of no more than a month during which a team creates one product increment (i.e. a piece of working software) that is potentially releasable.
Every Sprint begins with a Sprint Planning, an event that has two main purposes:
- Crafting a Sprint Goal — an objective that is to be met within a Sprint
- Defining a Sprint Backlog — a scope of work to be done to meet a Sprint Goal
To do the planning, a Scrum Team considers the Product Backlog, the latest Increment, as well as performance of a Development Team during the previous Sprints and its capacity (i.e. an average number of tasks that can be completed by a Development team during one Sprint). It’s also worth mentioning that while a Product Owner is responsible for picking stories to be developed, only a Development Team can determine a number of tasks it can accomplish within a separate Sprint.
Example:
Let’s say stakeholders provided Susan, a Product Owner, with seven feature requests (A, B, C, D, E, F and G). Susan assessed them and, after a discussion with stakeholders, made a decision that it’s not expedient to build C and E so only A, B, D, F and G were converted into users stories.
Susan knows that stakeholders value features B, D, F and G the most and they are critically important for the product. In addition, a Development Team told her that the development of features A and G would take a lot of efforts and the greatest amount of time. Based on this information, Susan decided that stories B, D and F should be developed in the first place because they are most valuable and the smallest.
The capacity of the Development Team is 2-4 stories per Sprint. At Sprint Planning, Susan discussed the selected stories with a Development Team, it assessed them and concluded that only two of them can be accomplished during the Sprint. Hence, it was decided that stories B and F would be the Sprint Backlog for the current Sprint.
A Development Team also has daily 15-minutes meetings called Daily Scrums during which team members inspect the progress (i.e. what was done yesterday), make plans for the day and determine if there are any impediments that can prevent a Development Team from meeting a Sprint Goal.
At the end of a Sprint, a Scrum Team holds an event called Sprint Review. Its main purpose is to inspect what was done (i.e. the Increment) and to adapt the Product Backlog accordingly (if needed). Usually, stakeholders are also invited, so they can participate in the discussion.
There is also a Sprint Retrospective, a Scrum event at which a Scrum Team has an opportunity to analyze how the latest Sprint went and think about any possible improvements to the process.
FAQ
Bottom line
As you may see, Scrum is simple and indeed convenient framework that makes a development process faster and much more efficient. Opting for a team that works according to Scrum is always a wise decision since this methodology allows for the constant improvements and adaptations, so, in the end, you receive a product that perfectly fits your needs.
