A Nuance on Standup Reporting

The Daily Standup (aka, Daily Scrum) is the most frequent Scrum event. It is the event on which new Scrum Masters focus first, and it is considered to be easy to conduct. All of this is true, but ‘easy to conduct’ is not equivalent to ‘has no subtleties’. I want to share one of the very subtle perspectives on how an effective Scrum Master might facilitate a Daily Standup.

The Scrum Guide versions published in 2017 and earlier suggest that the developers answer ‘Three Questions’ in the Daily Standup to share: what they have accomplished, what they plan to accomplish, and what impediments they are facing.

However, The Scrum Guide published in 2020 removed these specific questions and emphasizes the developers’ self-organization:

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

So, how does an effective Scrum Master obtain a right view into this progress toward the Sprint Goal, and have the information to craft an actionable plan with the Developers?

There are two basic approaches to the reporting phase of the Standup, which is then followed with After Meetings or a "16th Minute" whole team gathering. The team make their reports either:

1.      Developer by developer on the backlog work items (stories or tasks) in the Sprint Backlog, or

2.      By work item number following the priority ordering of the Sprint Backlog.

Each approach is more preferable than the other in some specific circumstances.

Reporting by Developer

I have found this approach is especially valuable when I am guiding a team of inexperienced developers, or a team new to the Scrum events.

Inexperienced developers often fall prey to goldplating—a failure of technical discipline resulting in the development of functionality that was not requested by a Product Owner or other requirements specifier. Goldplating is a Cardinal Sin of development because this unrequested code:

• Displaces legitimate, requested functionality
• May not be tested because it is not in the product requirements specification
• May contain bugs that jeopardize legitimate functionality, including being a potential cause of property damage or bodily harm.

Also, team members inexperienced in agile discipline often drift into working ‘off the books’ – that is, outside the work items in the Sprint Backlog. When such a developer reports without a work item number to shape a boundary around his report, it is not uncommon for me to hear, “I raised a pull request on story 19005, then I spent some time creating a utility we might need in the future.” The truth always surfaces and it is our role as Scrum Masters to obtain the truth.

One downside to reporting by each developer in sequence occurs if two or more developers are crafting the solution for a given work item. In this situation the report for that work item will be fragmented among those developers, and may require rework (i.e., repetition in the Standup) before the team understands the correct status of that work item.

Reporting by Work Item Priority

I adopt this approach when I have developers who are at least semi-experienced and disciplined, or when most of the work items have multiple developers assigned.

With multiple developers reporting on a given work item, this approach avoids the fragmentation I mentioned above. When each, or all, of the developers on a work item have reported on their respective tasks and accomplishments on their shared work item, the rest of the team should have a pretty complete understanding of the effort that remains to be completed.

Additionally, reporting by story number allows you, as a Scrum Master, to embrace the priority of each work item just as the developers should implement the Sprint Backlog work items in priority order. This allegiance to priority does not occur when reporting by developer name.

I find myself shifting between these approaches with the teams I coach. I am not averse to shifting even within a single sprint if I feel some suspicion about team progress or goldplating, or if I am suspicion that 'off the books' is occurring. I encourage you to experiment with the nuances above to the advantage of your team and yourself.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.