Locked lesson.

Upgrade

About this lesson

During a Sprint, the Scrum Team meets daily at a Scrum Meeting to provide status on progress.

Exercise files

Download this lesson’s related exercise files.

Scrum Meetings.docx
68.1 KB Scrum Meetings - Solution.docx
92.2 KB

Quick reference

Scrum Meeting

During a Sprint, the Scrum Team meets daily at a Scrum Meeting to provide status on progress.

When to Use Scrum Meetings

Scrum Meetings need to be daily activities (or sometimes even twice a day) during the Sprint. What time during the day is a decision that the Scrum Team can make.

Instructions

The purpose of the Scrum Meeting is to provide status and to integrate the activities of the Scrum Team members.

  • Meeting is held daily, at the same time and at the same place.
    • Occasionally I have seen Scrum Teams that wanted to meet twice a day due to the speed at which work was progressing.
  • Everyone on the team must attend.
    • Product Owner normally attends to answer questions, not to report on status.
  • The meeting is chaired and facilitated by the Scrum Master.
  • The meeting is normally held near the Scrum Board, if the Scrum Board is maintained virtually, it is projects on a screen or monitor.
  • Story Cards are moved to appropriate columns.
    • Each Scrum Team member provides status on the Stories and tasks they are working on – every team member reports.
    • Those that have met the “Demo Criteria” are moved to Done.
    • Those that are started and in work are moved to WIP.
    • My practice is that a Scrum Team member can only have 2 cards in the WIP column.  They must complete the work the work of one of those cards before they start anything else.
  • New Roadblocks are added.
    • Roadblocks are external barriers that are impacting the work, not just that something is hard to do.
  • Scrum Master provides the status of existing Roadblocks and removes those that are resolved.
  • The meeting result should be an updated Scrum Board once all Scrum Team members and the Scrum Master have reported.
  • Scrum Team members provide an estimate of how much work they have left to do on their cards that are in the WIP column.
    • No debate, just provide the number.
    • Number can be greater than the original value if a Scrum Team member has encountered a problem.
  • Scrum Master adds up the remaining effort in the “Sprint Backlog” column and “WIP” column to determine the current value for the Burn-down Chart and plots it.
  • A well run Scrum Meeting takes about 10 to 15 minutes depending upon the size of the Scrum Team.

 

Hints and Tips

  • These meetings can become long and boring if you allow the Scrum Team members to talk about “how” or “what” they did. You just want status. Did it start?  Did it finish? Are there Roadblocks?
  • A technique that I like to use to keep people focused on the cards is to have the Scrum Master go to each card in the WIP list and ask the Scrum Team member, “Did you finish yet?” and if it is still in the WIP column, “Are there any Roadblocks?” That way the Scrum Master does not give up the control of the meeting. If Scrum Team members want to talk about how a particular Story or task was done, cover that at the end of the meeting.
  • Once going down the WIP list, the Scrum Master should then ask each person which Stories or tasks they are working on, and if necessary move the card to the WIP column. Again, this keeps the Scrum Master in control and leads to a crisp focused meeting.
  • The Scrum Master goes down the list of Roadblocks. If the resolution of a Roadblock is a long discussion, the Scrum Master should do that outside the meeting with the appropriate Scrum Team member.
  • Don’t let a Product Owner turn the meeting into an impromptu Sprint Demo by asking about the result of each Story. The Product Owner should go to the Scrum Team member after the meeting if they have questions.
  • If a person is on the same Story or task for 2 days in a row, or the estimated effort is burning upwards instead of downwards, the Scrum Master should probe for any roadblocks and the rest of the team should provide assistance to help the individual having problems with their Story – especially if it is now the highest priority item. 
Login to download
  • 00:03 Hi, this is Ray Sheen.
  • 00:04 Let's talk about the Scrum meeting.
  • 00:07 We've discussed this briefly, now it's time to really dig in, and
  • 00:10 find out exactly what happens in these meetings.
  • 00:13 Well it starts with the fact that this is a daily pulsing meeting.
  • 00:18 Similar to what some organizations do with daily stand up meetings.
  • 00:22 In fact, in really fast moving agile scrum projects, you may meet twice daily.
  • 00:28 The best practice is to hold the meeting every day at the same place and same time.
  • 00:32 Establish that as a pattern.
  • 00:35 Start on time, end on time, and hold the meeting to just 15 minutes.
  • 00:40 Establish that as a discipline.
  • 00:42 These are focused status meetings, not a time for long-winded discussions and
  • 00:46 explanations.
  • 00:48 In the meeting, go around the Scrum Team and
  • 00:49 focus on the WIP column of the Scrum board.
  • 00:53 What have you finished and what can be moved to the done column?
  • 00:56 What have you started and should be moved to the WIP column?
  • 00:59 Are there any roadblocks?
  • 01:01 Finally, provide an update on the estimate of the remaining work effort for
  • 01:04 those tasks in the WIP column.
  • 01:06 This will clarify the current status of the project.
  • 01:09 You can move the cards on the Scrum Board during the meeting.
  • 01:12 That's my preferred approach.
  • 01:14 Or the Scrum Master can update the Scrum Board after the meeting.
  • 01:17 In addition, the Scrum Master will take the revised estimates for
  • 01:21 the WIP work, and the estimates for the stories and
  • 01:23 tasks that are still in the Sprint backlog column.
  • 01:26 Add those up and determine the estimated amount of time required
  • 01:30 to complete the Sprint, then plot that on the burn-down chart.
  • 01:34 Let's look at the Scrum Board, which is maintained during the Scrum meeting.
  • 01:38 The Scrum Board is the projects schedule status.
  • 01:41 We know the status of every story based upon its column.
  • 01:45 When it starts, it moves to WIP When it's finished and
  • 01:47 meets the demo criteria, It's moved to the done column.
  • 01:51 One of the ways that the Agile Scrum is different from traditional projects
  • 01:54 is that a Scrum team member is normally limited
  • 01:57 on how many stories they can be working on at one time.
  • 02:00 Instead of multi-tasking to the point where everything is started and
  • 02:04 nothing finished,
  • 02:05 we typically constrain the number of active stories to get focused activities.
  • 02:10 Some people use the constraint of a Scrum Team member and
  • 02:14 only have one story in WIP.
  • 02:16 I personally allow two but no more.
  • 02:19 In my experience, there's often a reason to put a task on hold for a hour or
  • 02:23 two, and it's good to have another one to work on.
  • 02:26 There's no requirement that they must have two stories and
  • 02:29 focusing on them one at a time is the best practice.
  • 02:33 Let's talk about roadblocks again.
  • 02:35 During this meeting the scrum team members should be identifying any roadblocks.
  • 02:39 Now, roadblocks are issues outside the control of the scrum team
  • 02:42 that are preventing the scrum team members from completing a story or a task.
  • 02:46 Roadblocks are not something that is just hard and slowing someone down.
  • 02:50 That is normal project work.
  • 02:52 The roadblock is an organizational or operational barrier
  • 02:55 preventing the team member from doing the work efficiently and effectively.
  • 03:00 Sometimes Scrum Team members run into problems and they don't want to admit it.
  • 03:04 If a story stays on the WIP column for more than two days,
  • 03:07 you need to dig in with the Scrum Team member and find out what is wrong.
  • 03:11 You probably don't have time in the scrum meeting to do that, but
  • 03:14 set a time after the meeting when the team member, Scrum Master and possibly one or
  • 03:18 two other team members sit down and look at what the problem is on that story.
  • 03:23 Don't let stories or tasks linger.
  • 03:25 Get them done and move on to the next one.
  • 03:29 Let's talk about the burn-down chart.
  • 03:31 This chart is different than what most project management charts look like And
  • 03:34 I find there are some confusion with it.
  • 03:36 The burn-down chart graphically shows the estimate for
  • 03:39 the amount of work still needed to be done to complete the sprint backlog.
  • 03:44 You may recall that the chart was initially baseline with the total
  • 03:48 estimated time of work To do the Sprint backlog on day one of the Sprint.
  • 03:52 And an estimate of zero work left to be done on day last of the Sprint.
  • 03:57 If the estimates were exactly correct,
  • 03:59 the amount of the remaining work would follow the straight line down to zero.
  • 04:02 But we all know that estimates will be off at least a little bit.
  • 04:07 So as people start to work on a task or
  • 04:09 story They will find that they need more or less time than estimated.
  • 04:13 They key to this chart is that Scrum team member
  • 04:15 does not tell the Scrum Master how much they have spent,
  • 04:19 rather they estimate how much more time is needed to complete the work.
  • 04:23 The Scrum Master will take all those estimates plus the estimates for
  • 04:27 the work that is still in the Sprint backlog column
  • 04:30 to determine the total estimate for the remaining work.
  • 04:33 That is the value that is plotted.
  • 04:35 At each scrum meeting,
  • 04:36 the scrum team members provide their estimate to the scrum master.
  • 04:40 Notice, the scrum master doesn't need to know how much effort was spent on
  • 04:43 the completed tasks.
  • 04:45 Those are done.
  • 04:46 So the estimate for completed tasks and storied is now zero, no more work to do.
  • 04:51 The burn-down chart can provide a good indication of the progress being made.
  • 04:55 The scrum board can be a little misleading.
  • 04:57 Because the amount of work in each story and task is different.
  • 05:01 The burn-down chart is just adding up the total measure of effort, usually in hours,
  • 05:05 and doesn't care about how much effort is spent on a particular task.
  • 05:09 So if the burn-down line is above the baseline
  • 05:12 The project will need more effort than originally planned.
  • 05:15 When that is the case it is likely that some of the stories of the Sprint backlog
  • 05:19 won't get finished.
  • 05:21 And if values are below the baseline the project is running ahead of effort and
  • 05:24 the Sprint backlog should be finished.
  • 05:26 In fact, the team may be able to do a couple of items on the not selected list.
  • 05:32 An interesting phenomena is that the chart can actually burn up.
  • 05:36 This would happen if the estimate to complete several tasks
  • 05:39 are raised significantly once the activity actually starts.
  • 05:43 If the task was first estimated to take four hours and
  • 05:46 it's now estimated to take 40 hours, the total of the remaining work
  • 05:49 may actually be higher than the previous days value.
  • 05:53 Doesn't happen often, and there's frequently a roadblock or
  • 05:56 two associated with this activity.
  • 05:58 A Scrum meeting is where the Scrum Master and
  • 06:02 Scrum team are able to keep their fingers on the pulse of the project.
  • 06:08 They're crisp, focused meetings, and they allow the Scrum Master to then
  • 06:12 update the Scrum Board and burn-down chart with accurate information.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course