... The development team is working in a scrum. During the course of a scrum, the team needs to know how they are doing.
✥ ✥ ✥
Without a frame of reference, it is easy for developers to "drift," not working at sufficient velocity to accomplish the necessary tasks. At the end of the sprint, they are surprised to find they didn't get as much done as they had initially hoped.
Although software development is a team sport, each person (or pair) works at their own velocity. Developers view the progress of the entire team through their own frame of reference, which of course, is not accurate. Therefore they get an inaccurate view of the team's progress.
In spite of our best efforts at design and estimation at the beginning of a sprint, we will be wrong. Finding out at the end of the sprint that we were wrong does us no good.
The high degree of teamwork fosters close relationships within the development team, but a side effect is that it leaves little attention for (and from) the rest of the organization. This leads to teams feeling isolated. They don't see what is going on around them, nor to others see and appreciate what they are accomplishing.
The three questions of the Daily Scrum have an extreme local focus — they do not provide sufficient information to learn how the sprint as a whole is going.
Developers have their noses to the grindstone, and have little to no time to grasp the big picture — any big picture (including how they are doing as a team.)
Developers who are continually busy can become burned out or discouraged, especially if they don't see that they are making a difference.
Create status reports that show daily status (within the sprint) and larger project status, and post them where all development team members can see them.
Examples of status reports include:
Posting status is all about transparency, information sharing, and motivation.
The status must be presented in a way that it is easy and fast to grasp the meaning of the status measurements. Visual information is highly recommended. For example, graphs are useful to show trends over time.
Balance the desire to show a lot of information with the need to be simple and easy. Make sure that you do show the most important information. Don't go overboard with many charts and tables, because the most important messages will get lost.
While any member of the development team could have the responsibility to collect and display the data, it is a natural task of the ScrumMaster, and most teams will want to defer to the ScrumMaster. In fact, this pattern is very much in the spirit of Knight Of The Mirrors. The ScrumMaster might also use this in conjunction with Coach, Cheerleader, and Sheepdog.
Note that some metrics can be generated directly and automatically from the code. take advantage of it where possible; it makes it easier and more accurate.
How widely should information be shared? A general rule is that the information should be shared within the bounds of the team's Community Of Trust (see Coplien and Harrison). Obviously, the development team must be a Community Of Trust, and it should include the Product Owner. Beyond that, it depends on your own team and its trust.
Be careful that the data is not used for individual performance measurement or as a "hammer" to coerce extra work for team members. And be careful that it isn't even perceived as being used that way. If it is, trust breaks down, data might be withheld or even falsified, and the team breaks down. (McCabe refers to this as "teamicide.") Alistair Cockburn relates a story of a team that posted their daily status on the wall outside their cubicles. One day a vice president walked by, saw the status, and wrote "good job" on the sheets. The status sheets were removed the next day.
Of course, make sure that the status data collected and displayed is both accurate and relevant.
✥ ✥ ✥
When accurate daily data is made visible to the development team, the team gets a better idea of where they are. They are in a position to make in-course corrections during a sprint to help them achieve the sprint goal. They often do this of themselves, with little or no overt prodding from the ScrumMaster.
A related benefit is that it increases motivation in the team, particularly as they see progress being made.
If the team has strong results, they will be eager to share them with others, increasing the team's visibility and even prestige with others. Likewise, a team can feel part of a larger whole when it sees others' visible status. Note cautions, of course about Community Of Trust.