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 all backlog management to myself. I create the 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.

  • When you say you "create" the PBIs, do you mean you write the acceptance criteria, acceptance tests, etc. If you do this plus "all backlog management" then you are the Product Owner. I'm not quite sure what "the team leads within our department liaise with the other product owners" means though. Are those team leads on your Development Team?
    – onedaywhen
    Jun 6, 2018 at 13:02

3 Answers 3


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.

  • My goal is to remove any obstacles that distract them from focusing on meaningful, productive work. In this case, entering tickets into TFS. When I put on the "Scrum Master"/Project Coordinator hat, I decided I didn't want them wasting time trying to figure out what fields were required, what the right drop-down values were, and all that stuff. I took that responsibility on so they only had to worry about updating the remaining hours on the tasks each day. For me, it was about eliminating nonproductive work in favor of productive work.
    – Mike Hofer
    Jun 2, 2018 at 21:24
  • @MikeHofer A Scrum Master is not a "Project Coordinator". Combining the roles of Scrum Master with Product Owner or any kind of project management role makes it significantly more difficult for a Scrum Master to achieve his purpose on the team. Based on your question, you don't have much experience and no formal training - without being extremely savvy with the purpose of Scrum and the agile methods, I would advise against having one person play both roles. You should get a dedicated Product Owner as soon as possible for your team, or a Scrum Master if you are interested in continuing as PO.
    – Thomas Owens
    Jun 2, 2018 at 23:14
  • I'm far more interested in Scrum Master than PO. I'll fix our process so that it's correct, that's all there is to that. And I'll work with our department head to get a real PO put in place. Our department is weird: we provide services to many other departments, and don't really have a product of our own. But I'm migrating us to Scrum, for the transparency and accountability it provides. It's not easy, but it'll be worth it.
    – Mike Hofer
    Jun 2, 2018 at 23:25
  • 2
    @MikeHofer: For a department like yours, the role of PO should go to the person that has the authority to tell department A that their request has to wait, because department B is more important. Jun 4, 2018 at 13:13

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.