Scrum: The Daily Scrum

The Daily Scrum

The daily scrum (or stand-up) event is primarily for the development team. Others may attend but not interfere with the proceedings. This event is where the team updates themselves on progress in the last 24 hours, and then aligns on a plan for the next 24 hours that they believe keeps them on track to achieve the sprint goal. The sprint plan may be adjusted throughout the sprint to ensure that the sprint goal is achieved, or at least that maximum possible value is delivered.

What: A daily event where the team meets to Check and Adjust the sprint plan
Who: Dev. Team, Product Owner, Scrum Master
When: Daily, 15 minutes

 

Agenda

  • Inspect progress towards meeting Sprint Goal since the last Daily Scrum
  • Plan work for the next 24 hours

 

Outcomes

  • The team has an accurate assessment of the current sprint progress and impediments
  • Team has made any necessary adjustments to the sprint plan to maximize likelihood of achieving sprint goal
  • Plan adjusted to correct WIP and Flow problems (address multitasking and bottlenecks)
  • Team has a solid plan for the work required in next 24 hours.
  • The scrum board is 100% accurate
  • The burn-down chart is up to date

 

SAFe Considerations

Scrum teams who are part of an ART have broader concerns than solely optimizing the narrow objectives for their current iteration. During the daily inspect and adapt event (aka daily scrum or stand-up) teams will identify impediments and challenges as they emerge and potentially impact not only the team’s objectives, but those of the overall PI. If the purpose of the stand-up includes some level of re-planning, then teams need to be aware of each others progress and delays. A scrum-of-scrums (or ‘ART Sync’) can be used to synchronize the work of multiple of teams, enabling teams to adjust their plans based on the other teams’ progress. Having good visibility into the state of the program using radiators like a program wall-board is invaluable for keeping teams synchronized on goals and progress at both team and program levels. Impediments and risks that have the potential to impact the overall program must be escalated promptly to the program team for resolution or at least mitigation. Transparency is key, and bad news can become worse news if delayed. The program team should be focused on optimizing the value delivered from the overall ART, and needs visibility of risks or impediments from all teams.

 

Details

The daily stand-up. Is it a status update or a planning session? Its intended to be a combination of both – a Check and Adjust session – the last 2 steps of a PDCA (Plan-Do-Check-Adjust) cycle, repeated on a daily basis. In order to determine if adjustments to the current sprint plan are needed the team needs an accurate picture of the current state of play, that is, they first need to check their status. Most teams do that part reasonably well, however many stand-ups look like they are exclusively devoted to  status collection, with everyone mechanically reciting the  3 stand-up questions: what did I do yesterday, what will I do today, and do I have any impediments. At the conclusion of the session the team returns to their work without any real reflection on whether any adjustments to their plan might be necessary. Below we’ll talk about why continuous attention to and potential adjustment of the sprint plan is important, and how teams might approach this.

Think of scrum as a set of PDCA (Plan-Do-Check-Adjust) cycles, where the plan, the product and the process used to build it are constantly inspected and adjusted in order to arrive at the best possible solution:

  • Plan: Sprint Planning
  • Do: Execute the plan – construct the increment
  • Check & Adjust the plan: Conduct a daily stand-up to check progress towards meeting the sprint goal, and if necessary, adjust the plan to ensure maximum user value is delivered at the end of the sprint.
  • Check & Adjust the product: Conduct a Sprint Review, demonstrate (check) new product capabilities and get feedback from stakeholders. This review may result in changes (adjustments) to the product backlog.
  • Check & Adjust the process: Conduct a Sprint Retrospective to check for gaps between sprint goals and actual accomplishments. Determine underlying root causes and identify corrective actions (adjustments) to the team’s development practices.

 

All 4 scrum ceremonies reflect an empirical (inspect and adapt) approach to the complex nature of software development. The daily stand-up is the inner loop of the sprint cycle, where on a daily basis, the team checks their progress against the sprint goal, and makes any adjustments necessary to stay on track. This is done on a daily basis to enable a fast response to emerging problems or opportunities.

Scrum Framework
Scrum Framework

But to do this the team needs an accurate picture of current status to see if any changes are needed. I have witnessed teams mechanically go through the Three Questions day after day, ending with a ‘No blockers!’, oblivious to the fact that they were marching off a cliff and about to leave behind a pile of unfinished stories (no value delivered). Many teams do a suboptimal job at sprint execution because they fail to manage the flow of work in an effective way. This is usually the result of having no information radiator on which to manage the inevitable queues and bottlenecks that tend to arise on a day-to-day basis. They can’t see the forest from the trees. I encourage teams to drive the stand-up from a dashboard with at minimum:

  1. A sprint burn-down chart in story points (not hours).
  2. A scrum board, with work organized in swim-lanes and tracked with a simple work-flow like: To-Do >> In Development >> In Test >> Done. Please do not construct swim-lanes around individual team members. This is guaranteed to stifle collaboration. Track the work, not the people. Swim-lanes based on sprint objectives or features, might bring better clarity to how the work is organized.

A well-designed scrum board can really help the team decide on flow decisions by making it obvious where the bottlenecks are, and what actions to take.

 
Iteration Burndown Chart
Iteration Burndown Chart
 

Scrum masters should get these charts in front of the team before getting into the details, the question being addressed is: Do we have a clear picture of our current progress? And, do we still believe we can achieve the sprint goals? If not, what adjustments to the sprint plan are needed? The team should discuss any obvious problems with the sprint first (e.g. a horizontal or ‘hockey-stick’ burn-down chart). Solutions to these problems might be obvious from the scrum board. Work the board from right to left. Look at WIP in each work-flow state, check the age of individual stories in each state – is this a large story, or are there other problems preventing progress? Is there a bottleneck developing in test? Can developers help unblock the test bottleneck?

Team Scrum Board
Team Scrum Board

At the conclusion of the stand-up we should have:

  • The scrum board is 100% accurate
  • The burn-down chart is up to date
  • Plan adjusted to correct WIP and Flow problems (address multitasking and bottlenecks)
  • Story priorities adjusted if necessary

The In Progress column should reflect only the work that the team believes they can actually complete within the next few of days. (Don’t park work items there unless they are actively being worked on).

What we are recommending is 100% consistent with lean principles:

  • Make Work Visible: Board and Burn-Down Chart at every stand-up. No other reports should be necessary to communicate an accurate picture of the sprint, together with any problems or risks.
  • Manage WIP (work in progress): Ideally no more than 1 item per team member (multi-tasking actually slows throughput). Encourage team members to only pull items from To Do to In Progress when they are confident of completing them.
  • Manage Flow: Identify any build up of queues or bottlenecks. A well-designed board should make these easy to identify. Look for items that appear to be stuck or blocked and deal with them (Move them back to To Do or Blocked, and replace them with other work that has a better chance of being completed). The In Progress column should represent work that the team is highly confident of completing in the sprint.

The team should always know the exact status of the sprint, and what immediate actions should be taken to ensure that maximum value will be delivered. The goal is delivery of maximum business value in every sprint – not to end the sprint with an assortment of partially completed stories. To do this, check and adjust daily.

 

 

Print Friendly, PDF & Email