View source | Discuss this page | Page history | Printable version   

Scrum/How-to for ScrumMasters

This article provides a basic guide to Scrum for those in the role of the ScrumMaster.


Enforcing the rules

You are there to enforce the rules and protect the process. Step in whenever team members or product owners are attempting to violate the rules or work around its safeguards.

Some typical examples of things you should catch can be found in the "What to do if" section below.

Ensuring built-in quality

Make sure that both the product owner and the team take done-is-done seriously. The product owner should not accept work that is not properly documented and tested. The team should not accept work that cannot be fully done in the sprint. Stimulate collaboration with team-external QA experts in the company when the team is losing sight.

Things to remember a few days before Sprint meetings

A few days before finishing a sprint and planning a new one you should take care of these checkpoints:

Your role in a Review meeting

These are the detailed steps you should check off during the Review meeting:

For our statistics please also check these items, though not Scrum-related:

(also see the internal wiki article

Your role in a Retrospective meeting

These are the detailed steps we currently follow during a Retrospective meeting at Openbravo:

Your role in a sprint planning meeting

Your job in the Sprint planning is to make sure that the Product backlog is understood and estimated for the upcoming tasks, that the team commits their work quantum and that a proper detail plan is being made.

These are the detailed steps needed for the way we currently work at Openbravo:

Part 1:

Part 2:

Your role in a daily scrum meeting

In principle you should not need to ask the team members to give their status in the Daily scrum. However often you may need to push them a bit.

Also watch out that

What to do if...

The team is delayed by work that was not planned as part of the sprint. Ask the team to deflect any such requests to the Product owner for prioritization. If they are really so urgent he will abort the sprint, otherwise they will be planned regularly.

The Product owner is trying to push in additional work into the sprint or trying to change the priorities. Ask the product owner to update the product backlog accordingly. Set up a brief formal meeting to discuss the proposed changes (essentially a small sprint planning for the changes), have them estimate and have the team decide which items they think they could take. In case of priority changes also ask them which items would have to drop out instead.

The remaining work looks too much and you suspect that the team is not going to be able to make their sprint plan. Ask each team member critically. Ask the team to identify things they are not sure whether they can deliver them on time. Flag this to the procuct owner and ask for a brief formal meeting to decide whether/what things should be dropped from the sprint.

Some team members dominate the discussion in a planning meeting and the others just follow their estimations. Try to stimulate the discussion by asking silent team members for their opinions or use planning poker cards to establish a level playing field.

The Product owner pushes his opinion about how long tasks should take and which items should be in the sprint onto the team. Ask him to refrain from doing this. If interference is too strong, ask him to leave the meeting until the team has discussed feasibility on its own.

The Product owner is planning items in a waterfall manner. First scheduling a specification document, then development, then testing etc. Remind him that this split of tasks is not acceptable and have him break down the tasks along iterations instead. If he says it cannot be done call in a meeting with the team to discuss possible iterations. Also remind the team that they should not accept such tasks as it violates their responsibility to deliver complete work.

The Product owner plans things with hard deadlines. E.g. he promises features to a customer for the next sprint without leaving planning room for the team and without space for iterations. Remind him that this is not acceptable and that iterations should be used and committments must only be made after the team has committed to a sprint.

The Product owner has decided to abort the current sprint. Set up a Review and Sprint planning meeting to collect the final status of the current sprint and plan a new one.

An background task (a task with no fixed work result, e.g. "help incoming support emergencies") is consuming more time than expected. If the time consumption presents a risk to the sprint goal discuss whether it can be shut off (e.g. "support requests have to wait for the next sprint now") or needs to go on. If it needs to go on, replan as you would normally do for excessive work quantity. (This problem is one of the reasons why such background tasks should be avoided where possible)

Retrieved from ""

This page has been accessed 10,034 times. This page was last modified on 14 April 2010, at 13:37. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.