Your Daily Scrum is over; that crucial 15 minute face-to-face every 24 hours which should prepare all the team for a better planned and more logically structured workday. To reduce the risk of drifting aimlessly through your project towards its final destination, surely even this short meeting needs some sort of reporting. Or, does it?
A Report or a Report?
From the outset, we need to clear up one basic thing. If you’re au fait with the extensive literature on Agile Methodology regarding the subject of the Daily Scrum, you’ll have noticed that there is sometimes a bit of ambiguity regarding the word “report”. Are we talking about the “report of progress” from individual members of the team or some form of “written daily report” compiled as a result of the Daily Stand-Up meeting? The former is what is usually thought of, but the real answer is that both types of reporting can exist so it’s advantageous to take a few minutes to consider the relevance of each. Don’t forget though; where Agile Methodology is not ambiguous, is in its demand that any type of reporting is quick, easily read, understandable, and accurate in order that it achieves results that provide value to a project. Moreover, any report should be aimed at the appropriate target audience.
*Regarding terminology; also note that everyone should be very aware that we are not talking about a Status Report here, ie the status of a project’s overall progress. An accomplished Scrum Master should be the one stopping the Daily Scrum turning into this.
The Target Audience
If you want to be effective and gain positive results with anything you write or say you must consider the needs of your target audience. In the Daily Scrum that target audience is made up of those in attendance, namely the team members and the Scrum Master. The Product Owner is most likely also there along with any other interested stakeholders but, whilst not being active contributors, are definitely part of the audience you need to be aiming at. All are consumers and users of reporting, requiring information for different reasons at different levels of complexity.
Report of Progress
The Daily Scrum provides an opportunity for all team players to report on three basic points:
- What they have done since the last meeting.
- What they expect to achieve by the next meeting.
- What problems they face.
From these three points, the following can be understood:
1. The progress of individual parts and how they fit into the overall picture. In other words, you are able to check on the accomplishment of goals your team committed to the previous day. So you can learn if team members are setting themselves achievable goals or perhaps, if they are not stretching themselves enough and thus slowing down progress. Moreover, you are able to quantify the development of a project.
2. What you are able to forecast for the coming 24 hours. Namely, what targets are team members setting for themselves. By knowing this, you can comprehend how much further the project is likely to develop over the next day based on the predictions of the team members in relation to their past achievements.
3. Where individual team players have blockers. That is to say, a list of the obstacles faced and ideas on how to solve them. Although blockers should not be dwelled upon and discussed in detail within the Daily Scrum, by highlighting them it allows the Scrum Master in particular the opportunity to delegate and assign problem solving exercises to others.
How It’s Reported
The Task Board is utilized as a written record of the above criteria. A simple accessory, usually in the form of a whiteboard on which three columns are drawn and labelled: “To Do”, “In Progress” and “Done”. Additional points, where required, can be easily added, for example, regarding some sort of problem which others can be of assistance with. This serves as a visual focal point for the Daily Scrum and can be updated frequently, keeping the whole team constantly aware of progress and obstacles. In effect, it is an ongoing graphic report to which everyone has access; adequately detailed but easy to understand.
In addition, the Burndown Chart is another form of graphic report which is also updated at frequent intervals. Depicting the amount of work remaining on the vertical axis and the time elapsed on the horizontal, it is more specific to the overall progress of a project but, in practical terms if updated daily, can be seen as another report tangible relating to the Daily Scrum.
Definitely the Task Board, and perhaps the Burndown Chart, are reports on the Daily Scrum. The Product Owner and other parties involved in a project usually don’t have the luxury of time to read through extensive reports so these two accessories provide easily understood updates. Bear in mind that reports which really matter are those that measure if you are heading towards or away from the results which you are seeking to achieve.
*Some Scrum Masters and other attendees prefer to take notes on the Report of Progress from individual team members. This should not be discouraged, as it undoubtedly aids their personal involvement in a project, but cannot be regarded as real reporting in this context.
Written Daily Report
A Debatable Subject
Living in an era where some form of written report seems to be a safeguard necessity in the majority of organizations, following virtually every action or event, you may automatically assume that your Daily Scrum requires the same. Certainly, this would seem the case but many people doubt this policy based on the fact that Agile already makes use of other reporting devices.
Those in Favour
“We should report as much as we can.” We’re not designing and developing a simple new wooden toy for a two-year-old child here, this is computer software development, a highly complex and cost-intensive sector of project management. Without a flow of regular and detailed written reports highlighting development plus any related problems, our project can run the risk of going off-course very easily. Written reports provide definitive value to both the on-going project and to any of those that we are proposing for the future.
“Reports help players.” Let’s not go too deep into the world of “Psychology of Man in the Workplace” but probably most would agree that the average person needs to feel responsible, be held responsible and, feel a sense of recognition for their achievements. If these emotions are not being addressed then it will quite possibly lead to demotivation issues. If meetings are being reported and are available to everybody in the hierarchy to read and digest, individuals and teams will almost certainly have a better sense of their accountability and, at the same time, be more satisfied with their role in a project and its progress.
“There’s already enough reporting”. The concept of being Agile in project management has its roots in the idea that processes need to be more flexible and productive. Thus, it could be argued that adding another layer of documentation contradicts this basic principle by further slowing down the whole thing with more time-consuming report writing. Similarly, critics point out that adequate visual reporting already occurs, via the use of the Task Board and Burndown Chart mentioned above, so why do we need to have anything extra?
“Reports hinder players.” The suspicious individual may well see a written daily report as a type of appraisal of their work output. Used to a six-monthly or annual review of their contribution to the business, it implies that Big Brother is watching you all the time. On the other hand and in complete contrast, if used in this way, it could be viewed as a serious positive by the HR department and the boss. This utilization of written reporting is seen as a big “no-no” in pure Agile Methodology but in the real world of business, is there any better way than daily feedback to assess an individual employee’s performance and suitability?
So, what can you tell from your Daily Scrum Report?
A fundamental of Scrum Methodology is the concept of individuals providing a report of progress at each Daily Scrum. If team members are not doing this reporting, then you’re not really using this genre of Agile and certainly won’t be able to tell much from your daily stand-up meetings. So, probably all would agree that this is a necessity.
However, as regards some form of written report following each Daily Scrum, the Jury is still out considering its verdict. As in all balanced arguments, you and your organization need to consider and judge both sides; are retrospective written Daily Scrum Reports necessary in your work environment or are they just another addition to unwanted paperwork and bureaucracy? Different people within your project can tell a lot from such reports but, ultimately, what use you make of them has to be your own personal choice. If a report (and its results) has no value and is a time-waster, then don’t create it.
Quite recently though, an attractive alternative has emerged with Asynchronous Stand-Up Meetings in Slack, namely on-line meetings not necessarily occurring at the same time. An independent third party can provide both sorts of reports, acknowledging the significance of documentation and sharing without the negatives outlined above and, more importantly in a practical way, not having to have everyone physically together at the same time in the same place. Progress reports are contributed online by the team members and then posted for all to see. Hence, there are permanent “hard-copy” reports available, which can be referred to at any time.
But, to sum up, what you wish to happen in your reporting and what you want to get out of it, is ultimately for you to decide.