Information radiators (IR) are used to help teams see information transparently so they can make fact based decisions about how they want to change. But how do you know which information radiators to use with a team? How do you know how many are needed and what to display?
The best way to use information radiators is in response to something you see or something the team is struggling with but needs a way to really understand what’s happening in order to grow.
In the story below a Scrum Master started using this version of a sprint (points) burn up so her team would have a visual representation of how they were actually working together during sprints as a basis for which to develop improvement experiments.
- Symptom #1 they were consistently not finishing all of the work in the sprint
- Symptom #2 they were starting a lot of work at one time in the beginning of the sprint but rushing to get work tested and accepted during the last two days of the sprint
- Symptom #3 they were carrying over stories and said that it was okay because it gave the testers something to do while the developers were heads down during the first 8 days of the sprint – which indicated that they were actually doing mini-waterfalls.
- Symptom #4 they were adding stories to the sprint after it started before the original work was complete weren’t finishing the new work brought into the sprint
During the first sprint review they analyzed the burn up and noticed that the green bars that represent points accepted did not show up until the last two days of the sprint.
- They realized that starting a bunch of stories and working on them separately didn’t make them go any faster because it created a bottleneck in testing at the end of the sprint which left some stories unfinished.
- They decided to pair up or swarm on work in order to open fewer stories at one time and get them tested and finished earlier in the sprint.
During the next sprint they paired on work and focused on finishing rather than starting work. At the end of the sprint they analyzed the burn up again and noticed improvement, but not enough.
- They realized that they were less successful completing larger stories because they took longer to develop which caused them to start testing too late in the sprint to finish.
- They decided to break stories into smaller more manageable pieces of value so they could finished them quicker.
During the next few sprints they noticed that working with smaller stories helped them close stories faster. By continuing to pair on stories and limit work in progress they found that they were able to more consistently deliver stories every few days during the sprint.
The team noticed that though they had begun to deliver at a more consistent rate they were still having problems finishing all of the work by the end of the sprint. They analyzed the burn up in their next retrospective to see if they could gain any new insights.
- They realized that they were actually finishing the number of points they originally forecast during sprint planning.
- They recognized that during days 4-6 they finished 10 points of work but they also added 10 points. They also recognized that every time they finished a story they seemed to add another which was contributing to why they had unfinished work at the end of the sprint.
- They decided to work on breaking down their tasks better so multiple people could swarm on stories.
- They also decided that instead of a developer bringing a new story into a sprint when there wasn’t development work on any of the stories the developer would cross over and help the testers with a story they hadn’t developed.
- Lastly they decided that in the last 2 days of the sprint, if there were no stories they could assist on they would focus on some smaller technical debt clean up tasks rather than bringing in new stories they would not have time to finish.
Over the span of a quarter the team was able to effectively make improvements to their delivery and predictability by using this information radiator to help them visually inspect their work habits. At the end of the quarter the team felt that acceptable improvements had been made and analyzing the burn up during retrospectives was no longer a value add so they abandoned that practice to focus on other improvement areas during retrospectives.