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.

Agenda

Outcomes

SAFe Considerations

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:

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.

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.

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?

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

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.