Can the Scrum Master role directly modify the Sprint Backlog?

Question

Our company is migrating to Scrum. I've been thrust into the role of Scrum Master (with no formal training—but I'm working on that). Our team doesn't have a Product Owner due to the structure of our company, and because we service all the other teams in the company. Instead, the team leads within our department liaise with the other product owners.

Up to now, I've centralized all backlog management to myself. I create the Product Backlog Items (PBIs) and tasks, with input from the team and team leads, in an effort to clear their plates of the minutia of ticket management.

However, I read this in The Scrum Guide today:

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

I am not entirely clear, from The Scrum Guide, whether or not the Scrum Master is considered part of the Development Team. In other courses, I believe the term Scrum Team refers to the Scrum Master, Product Owner, and Development Team, and the term Development Team refers simply to the product development staff (developers, testers, designers, etc.).

My question is, should I be hands-off when it comes to the Sprint Backlog? Should the developers be creating tasks on the Sprint Backlog as necessary?

I have a sneaking suspicion I'm doing this all wrong.

Answer 1

The Scrum Master is not part of the Development Team. Your assessment is correct - the term "Scrum Team" refers to the Scrum Master, Product Owner, and Development Team. The Development Team includes all of the people who are doing the work to transform Product Backlog Items into a potentially releasable Increment at least at the end of a Sprint.

If the Scrum Master is doing work toward the potentially releasable Increment, then the Scrum Master is also on the Development Team. The person with the role of Scrum Master also has a role of Development Team member.

It sounds like part of the confusion is between the Product Backlog and the Sprint Backlog.

The Product Backlog is a list of "all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases" (from the Scrum Guide). Each of these individual items on the list are Product Backlog Items. The Product Owner is responsible for the Product Backlog.

Product Backlog Items are refined by the Scrum Team. The Product Owner and Development Team collaborate on the process of refinement. The Development Team makes sure that each Product Backlog Item has enough information to implement and any details or questions are addressed. The Development Team also provides an estimate to aid the Product Owner in ordering the Product Backlog and understanding when work may be completed.

In Sprint Planning, one of the outputs is the Sprint Backlog. The Sprint Backlog starts as a set of Product Backlog Items that were planned for the Sprint. However, there may be discrete elements of work that the Development Team identifies in planning. These items are also added, by the Development Team, to the Sprint Backlog. Throughout the Sprint, the Development Team is responsible for maintaining the Sprint Backlog.

These Sprint Backlog Items (my term - not something found in the Scrum Guide) aren't estimated. They are simply things to support transparency. By breaking down the work into more fine grained elements, the Development Team gives the Product Owner and themselves more visibility into the work being done in the Sprint. The idea of putting these work items into the Sprint Backlog is to ensure that the team knows what work is required, help people to focus on work that needs to be done, and to identify if there are threats to achieving the Sprint Goal.

The Development Team should be the one creating Sprint Backlog Items, at least at a conceptual level. However, that doesn't necessarily mean that the Development Team will create the Sprint Backlog Items in a ticket tracking tool. Perhaps the Scrum Master will do that. Just like how the Product Owner can delegate some work, the Development Team can also. Perhaps it makes sense that, if a ticket tracking tool is used, the Scrum Master may be asked to enter the work there. One of the responsibilities of the Scrum Master is to facilitate Scrum events, and ensuring that work is appropriately entered into the ticket tracking tool facilitates the refinement of Product Backlog Items as well as Sprint Planning and perhaps Sprint Review and Retrospective as well.

A question for you: As Scrum Master, are you facilitating the team by removing the concern of entering work into a tracking tool? Or are you entering work with the intent of instructing the team on how to turn Product Backlog Items into a potentially releasable Increment? One is consistent with the principles of Scrum. The other is not.

Answer 2

TL;DR

While well-intentioned, what you are currently doing is not very agile and likely to be counterproductive in adopting Scrum properly over the long term. Your current process does not adhere to the Scrum framework, the values or principles of the "Manifesto for Agile Software Development," or empower or coach the Scrum Team and the rest of the organization in becoming more agile.

Some of this is certainly due to misunderstanding the roles and accountabilities of the framework, but some of the problems are likely organizational challenges that a newly-appointed Scrum Master is unlikely to have the experienced eye to identify easily. If the whole organization is new to Scrum, it's generally insufficient to adopt the framework without ensuring that everyone in the organization understands the process changes required to truly benefit from the mind-shift required to properly implement agility.

Organizational training, rather than just training for one or two individuals on a given Scrum Team, is probably required. If I were in your shoes, I would certainly recommend it to senior leadership.

Some Things to Consider Up Front

1. The Scrum Master and Product Owners are roles within the Scrum Team and are members of the Scrum Team, but except for shared responsibility for various goals the roles do not share the same core accountabilities of any other role.
2. The Scrum Master is a Scrum Team member, but the role is distinct from the Product Owner and Developer roles, and the role should not preempt the accountabilities of any other roles.
3. The term "grooming" was replaced at least one or two iterations of the Scrum Guide ago. It is now referred to as "refinement." You can search this site for discussion on that.
4. The Product Backlog and the Sprint Backlog are different artifacts, owned by different roles. Neither is the Scrum Master. Your question is therefore confusing on its face.
5. You are missing roles and an understanding of the distinction between several roles and artifacts. That's adding to your confusion (and likely the rest of the team's) about the Scrum process.

Scrum Has Immutable Roles

You must have a singular Product Owner for Scrum. If you don't have one, you may be doing something Scrum-like, but you aren't actually following the Scrum framework.

In addition, while there's technically nothing preventing one person from fulfilling multiple roles such as Product Owner and Scrum Master, that's often an anti-pattern and frequently a conflict of interest. Still, while other product people and stakeholders in the company might have input, the Scrum Team must have a singular person in the Product Owner role for Scrum.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

In addition, the Scrum Master does not manage the Product Backlog or Sprint Backlog, nor does the Scrum Master task out the Developers. The Scrum Master role has clearly-defined responsibilities, and those are not among them.

Scrum Defines Artifact Ownership

The three key artifacts in Scrum are the following:

• Product Backlog
• Sprint Backlog
• Increment (including the Definition of Done)

The Scrum Team as a whole is responsible for delivering the Increment, but the two backlogs have formal ownership. In particular:

1. The Product Owner is solely accountable for the Product Backlog.

   The Product Owner is also accountable for effective Product Backlog management, which includes:

   • Developing and explicitly communicating the Product Goal;
   • Creating and clearly communicating Product Backlog items;
   • Ordering Product Backlog items; and,
   • Ensuring that the Product Backlog is transparent, visible and understood.

   The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

2. The Sprint Backlog is a plan for the Sprint solely by and for the Developers. It includes a number of things, but the Developers are the only ones who should be managing it.

   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).

In practice, what this means is that what you are currently doing is not only not agile, but is preventing the Scrum Team from becoming empowered and self-managing. Agility requires adaptation, and Scrum Theory is clear that:

Adaptation becomes more difficult when the people involved are not empowered or self-managing.

While your intent is to be helpful, by allowing a ticketing system to drive your process is an anti-pattern. Furthermore, by defining the tasks for the Developers rather than allowing them to hammer out how will the chosen work get done during Sprint Planning, you are usurping the Developers role within the Scrum Team and preventing them from creating goal- and outcome-driven emergent designs and just-in-time delivery processes optimized for their individual and collective skills. This is basically traditional command-and-control project management with an ersatz Scrum wrapper, and is unlikely to net you the real benefits of a mature, self-managing team that practices continuous improvement.

Answer 3

Your understanding is correct, the Scrum Master is not part of the development team, but both the Scrum Master and development team, along with the Product Owner are collectively known as the Scrum Team.

WRT the question of ‘Can the Scrum Mast be part of the development team?’

I have come across situations where the Scrum Master was part of the development team i.e. they had a dual role. This was in a smaller company which didn’t have the ability to fully staff. It worked however raised the issue of potential conflict of interest.

As the Scrum Guide prescribes, the Scrum Master will ‘Coaching the team members in self-management'. So if they were also part of the development team then several possible issues could arise:

1. Would they feel comfortable in putting their view forward? Would it be taken as a view of the developer or scrum master. If the latter then its not allowing the group to self organise, however if they hold back their opinion then they are not doing the role as a developer.
2. If as part of the development team discussion, an issue arises with the groups understanding of Scrum, do you then switch roles to Scrum Master and facilitate their understanding?
3. In the case of multiple teams and the developer in one team is the Scrum Master, then you really have the possibility of a conflict of interest

Having said that, as the Scrum Master is a facilitator, there is a possibility for this to work, and in situations where I have seen this, the Scrum Master will work for the majority of time in the developer role. So really it depends on the situation and the person, does the person have the skills and maturity to wear multiple hats?

Something I try to keep in mind is never asking people to do something that I am not willing to do myself, so from that point of view, it could be beneficial.

WRT the sprint backlog, the Developers are always accountable for creating it, and during the daily scrum this may be adjusted as required. Worth noting as well is that the Scrum guide also states that ‘If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers’

Answer 4

Essentially this rule is trying to balance two things.

1. Prevent addition or changes to the scoped work for the sprint.

2. Prevent additional or changes to work that happens anyway from being un-recorded

If the dev team could literally only do exactly what was on the sprint backlog any mistake in planning or missed detail would be a massive problem.

They need to be able to tweak the plan and those tweaks need to be recorded and show on the burndown etc.

But on the other hand changes to the agreed work undermines the whole point of having sprints. You need to push POs to put the effort in at the planning stage and not rely on being able to change their minds as work is in progress.

Answer 5

I think the key phrase from the Scrum Guide that applies here is this:

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Note it is the Development Team doing the explaining to the SM (and PO). A Sprint Backlog of items (tasks, artefacts, outcomes, whatever is needed) that focus on the Product Backlog items and the Sprint Goal is a great way for the Development Team to explaing how they forecast the Increment will me created.

Also consider the wording for the Daily Scrum that (not unconicidentally) uses much of the same language:

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint... the Development Team is responsible for conducting the Daily Scrum.

The Daily Scrum is one of the inspect and adapt events during the Sprint. The Sprint Backlog is insepcted: are we on track to complete the increment, will it meet the Sprint Goal? If not, then the Sprint Backlog needs to be adapted to best ensure a successful Sprint.

While the above concerns the Development Team, you as Scrum Master still have a role to play. You have to help the team do what is needed without actually doing it for them.

If you think the Development Team are have not sufficiently explained how they intend to deliver the increment then you need to decide whether to directly intervene. While it is OK to facilitate experiments for the Developers to learn from even when they fail, it is probably not OK to allow Sprint Planning to end when a failed Sprint will almost certainly result. And be conscious of the time-box expiring!

Similarly, you should be observing Daily Scrums and deciding to intervene early enough in the Sprint to best ensure success.