Scrum/How-to for ScrumMasters

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

Contents 1 Enforcing the rules 2 Ensuring built-in quality 3 Things to remember a few days before Sprint meetings 4 Your role in a Review meeting 5 Your role in a Retrospective meeting 6 Your role in a sprint planning meeting 7 Your role in a daily scrum meeting 8 What to do if...

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:

• remind the team to fill in their sticky notes for the Retrospective and place them on the right spots
• check with the Product owner that the Product backlog is ready for planning and that he's aligned with all external stakeholders
• check that the tasks in the Product Backlog are reasonably sized, and if not bring in the team and help him to break things down! (see the example in the Story points article)
• notify the central QA group of the upcoming planning meeting so they can align with the Product owner about the upcoming plans

Your role in a Review meeting

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

• Go through task list, have the team explain what they did for each item
  • check deliverables are met
  • check that status color and hours are updated
  • where applicable, have the team demo their achievement
• Update the numbers in the product backlog (if a task has been done, the number in the column of the new sprint will be zero, if not it stays)
• Add followup tasks to the backlog where further iterations are necessary
• Duplicate items in the backlog (to after the sprint finish line) and mark them grey, have the product owner sort them into according to their priority
• Tell the team how many storypoints they have achieved and put it in relation to the previous sprints (also man hours per storypoint) - all this is calculated at the end of the product backlog. Make sure to observe the rules for Stretch goals

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

• Check that all lines in the Sprint spreadsheet have an effort category
  • ask the Product owner to assign categories if any are missing
• Check that all tasks in the Sprint spreadsheet carry the time spent and that it is plausible given the available hours
  • ask team members to amend this information if missing
• Send an email to the Program Manager of Product Development (PNU) with the efforts of the finished sprint for each category, team name, sprint number and start/end dates

(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:

• Make sure everybody has filled in and placed their stickies
• Have the team members one by one talk about the items they have in the timeline
• Have the team members one by one talk about the items they have in the positive slide
• Have the team members one by one talk about the items they have in the negative slide
• Find useful groupings (solution-oriented) for items
• Discuss necessary solution steps for each item/group
• Move items to team or organization slides accordingly and define a next step for each
• Identify those items that are covered by previous retrospective items still on the current backlog
• Check the status of the other remaining open items with the team and if they want to keep them add them to the slides
• Have the items prioritized for each slide
• Remove stickie slides and export the finished slides as PDF, email them to the team for keeping
• Add team retrospective items to product backlog (below the past sprint)
• Add organization retrospective items to impediment backlog
• Carry over those retrospective items that are kept from the previous Sprint(s)

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:

• Confirm schedule, adapt sprint spreadsheet columns and dates if needed
• Confirm availability
• Confirm timing of next meetings and adjust calendar
• Go through the upcoming product backlog, add point estimates (newly added tasks starting always in the current sprint column)
• Clarify questions of the team and split tasks where necessary (e.g. milestones identifiable, task too big)
• Get first agreement on the point until which tasks should be accepted in teh sprint and move the sprint line in the backlog accordingly

Part 2:

• Copy the items from the backlog into the sprint sheet
• Add the free time task and calculate the hours (10%) available for each team member as per their availability percentage in the resources & holiday sheet
• Copy the retrospective items into the sprint sheet
• Identify clear deliverables for each story
• Derive as many subtasks as can be identified for each story
• Estimate the hours necessary for each subtask
• Check that the hours are within the expected available time calculated and do not overload specific team members while leaving others bored
• If hours are too many or too little call the product owner to decide which items to remove from the bottom of the sprint or which to add from the top of the backlog
• Report back the result of the planning 2 meeting to the product owner and reconfirm that the deliverables are as desired
• Ask the Product owner to assign effort categories to each task on the sprint (not needed for Scrum but our statistics)

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

• everybody attends - remind those missing that they have to attend
• everybody correctly gives their status including done, planned items and impediments
• you determine clear next steps for any impediments raised
• if people have not been able to finish what they had planned the previous day, find out why. Often this reveals an impediment that was not mentioned.

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)

Category: Scrum