Welcome to part two of our Scrum Basics Series. This part deals with the three different roles involved in the Scrum process. One thing to clarify right from the beginning: All three roles together form one Scrum Team. All are equal and neither the Product Owner (PO) nor the Scrum Master (SM) are superiors to the Development Team.
To function well they need to work closely together and, in an ideal world, also sit together in one room. They need to understand that they are ONE team, fighting for the same goal: to release the best possible product for the end-customer.
Development Team
A typical Development Team consists of 7 members +/-2 with cross-functional abilities. They should organise themselves and decide on their own, how tickets will be implemented within a sprint. It’s also the Development Team’s decision on how many tickets they decide to solve within a sprint. This freedom comes with the duty to commit completely to the goal to deliver all the planned tickets within a sprint.
To being able to know how many tickets they are usually able to solve within a sprint, the team estimates all tickets by themselves. Nobody else is allowed to give estimates for tickets but the Development Team as they will solve those tickets in the end. During the sprint, the Development Team also has the duty to track their progress. That means, they keep the Sprint/Scrum Board clean and move the cards across the board according to their progress. Everyone in the team, including PO and SM, should always know the status of each ticket within a sprint.
The most important task for the Development Team, also in Scrum, is to deliver. Just as in Scrum they can tell themselves how much time they need to deliver something, this gives them the freedom to achieve the big goal of the Scrum Framework: to deliver quality products.
Product Owner
The Product Owner is a very important role in Scrum. I’ve heard trainers say that a Scrum Team can rise or fall with their PO. The speciality in Scrum is, that the PO is not the boss of the Development Team, but part of the team. This is not easy, especially for POs who have worked as Project Managers in the past. In Scrum they are a lateral leader.
However, the PO determines what the team is going to develop next. They set up the Product Backlog and decide the ticket’s business value (containing a lot of information like how many customers would find a specific new feature useful, how long would the development take or how severe the impact of a bug is) and with that the ticket order. They determine an appropriate balance of fixing bugs and developing new features within a sprint. They spend a lot of time maintaining the Product Backlog, which means creating new tickets and prioritising them as well as keeping the Backlog up to date. Several techniques exist of how to prioritise a Backlog. The technique to be used mainly depends on the product the team is working on.
To create the tickets the PO is also responsible for gathering all the requirements as well as to talk to the stakeholders. Managing all the stakeholders for a product can be quite time consuming. But there are some techniques that can help the PO to keep an overview.
The PO’s superior task is to create a common product vision and to steer the product release. They are also responsible for accepting (or not) the developed tickets from the Development Team. As you can see, the Product Owner is a very important and complex role in Scrum and so it’s no wonder that several training sessions exist and that one should participate in before agreeing on this job.
Scrum Master
The Scrum Master is normally the most unclear role for people who are new to Scrum. The concept is just not existing in other frameworks and therefore the value of this role is often underestimated. After all, the Scrum Master is not directly adding development power to the team, so why should a company still invest in an extra employee?
The superior task of a Scrum Master is to protect the Scrum Team! And yes, this includes developers and PO. One example that most software developers probably understand is the problem of scope creep. The developers are working on their feature, when some manager steps into the room and forces someone to take care of an ultra-urgent topic. The developer is distracted from their actual task and since it was a manager who told them to go work on something else, they usually do it. Not in Scrum! In Scrum it would be the task of the Scrum Master to step inbetween the manager and the developer. The Scrum Master would tell the manager politely to go and talk to the PO, who will create a ticket for his request and sort it into the Backlog according to its business value. If it really is ultra-urgent, it will be solved within the next sprint. Only in real blocker situations (like a live-platform being down) a running sprint would be interrupted. And ONLY the PO has the right to decide this.
That little story already leads to the third biggest part of the Scrum Masters time: Coaching. His responsibility is to coach not only the team and the PO on Scrum and agile development topics, but also all other departments in the company that have to interact with the Scrum Teams. They need to know the rules to being able to follow them. Normally they also need a constant reminder of those rules. Coaching the Product Owner is another big topic. As you have already learned, the PO role is quite complex and there are several techniques that can help him in his daily business. But someone needs to teach him those techniques and also make him aware of problems. Only if someone tells the PO that something is not working, they can improve themselves and their work. The same goes for the Development Team. It’s the SM’s job to constantly push them to improve themselves, to become more self-organised and to be open for changes.
You may have noticed that I switched from the first to the third biggest part of the Scrum Master’s job, so here is the second: They have to ensure that impediments are removed. Impediments are all things that block the team from performing. If it is the manager in the room, a computer that’s too slow or a suddenly unusual high amount of support tickets: The Scrum Master needs to investigate and find a solution. That doesn’t mean that they have to solve everything by themselves. They only need to find the responsible people and ensure that they are solving the problem. Like pushing the decision maker for a fast “go” on a new computer to replace the slow one. To order and install it is then up to IT. Or the SM would have to investigate why there are suddenly so many support tickets. Has the quality dropped? Or is there a high sick-leave rate in the Service Center so they aren’t able to work in detail on every ticket and just pass them on? The SM would need to talk to them to understand if the Development Team should plan to do less tickets in the next sprint in order to have more support time.
Two more tasks are left for the Scrum Master to do: facilitating meetings as well as mediation talks. The SM is responsible to moderate all the Scrum meetings and to make sure the meetings start and end on time. But if they do their job correctly and improved the team’s self-organisation, they will soon take over moderation, e.g. for the review. Equally important are mediations skills. If there are problems within a team or also between teams the Scrum Master has to solve them. The SM needs to be the person of trust for every team member.
In total you could say the Scrum Master has to keep the process running. No matter what happens, he has to make sure the Scrum Team is still able to work on their tickets. For that, it’s also important to promote Scrum in the organisation. If for example the Marketing department knows that the Scrum Team shows their development results every two weeks, they might just join these meetings to be up to date all the time. If managers know the two-week time frames, they can go early to the POs and ask if there’s space for an additional task in the next sprint. Combine “protect the team”, “remove impediments”, “push for constant improvement” and “moderate meeting so they have a valuable outcome and end on time” and you can see where the value of this extra employee pushes in. I’ve seen Scrum Teams that were able to double or even quadruple their development speed, after they have been assigned a full-time SM.
Related posts
- Scrum Basics: What is Scrum?
- Scrum Basics: Scrum Meetings
- Scrum Basics: Estimating
- Scrum Basics: Principles and Values
- Scrum Basics: Practicing it
About the author
