What is the "Physical Information Radiators" in the context of Scrum?

Question

I'm pretty new to the Scrum thing. I'm reading more and more of it. I'm very enchanted by the idea.

I visited this page about the 12 points of the Scrum framework by Scott of Rapid Scrum.

What is the "Physical Information Radiators" that he's referring to under the "Three Best Practices"?

Answer 1

Physical information radiator is pretty much anything which:

• is visible by pretty much anyone in the team
• shows meaningful information regarding the project/team/application/etc.
• isn't software per se, which means you don't need a computer to access it

A few examples of radiators:

• Task board. Probably the most canonical and most common example. Board where you show tasks being done during sprint. Usually there are stages to how where a story is (e.g. development, testing) and some indicators who is doing what.
• Burn-down/burn-up charts. It shows how the team is doing against the sprint plan.
• Build information. Often teams presents results of build in some way. It can be either fancy orb as Tangurena suggests or just a monitor showing statuses of projects built on a build server.
• Critical situations. Some teams use distinctive indicators whenever something really bad is happening, e.g. there is a critical bug to be solved. Often such information is shown on a task board.
• Commonly needed information. In one team we had the architecture of application drawn on a whiteboard. As we were changing the architecture rapidly the drawing were becoming more and more complex but that was the easiest way to refer to it and to adjust it until it stabilized a bit and we moved it a document.

Answer 2

An information radiator is a scoreboard that shows anyone/everyone what is going on. Some other examples include using an ambient orb to show colors (red, yellow, green) very easily.

Answer 3

To give you an example, here's a photo of one of our team's automated Information Radiators, which provides a continually present summary of metrics important to us. Each part of this screen is dedicated to monitoring a different aspect of our development pipeline or operational systems.

The bottom left quadrant contains the status of our CruiseControl.NET builds. If a developer commits code to the source code repository that fails to compile, fails the automated tests or cannot be automatically deployed, a segment will become red. Across the top are sections for each staging environment: internal test (alpha), UAT (beta-testing) and live (production). The display also contains sections for monitoring the performance of key services to provide early warning of application or infrastructure issues.

We've found this ability to visualise the system in real-time gives us a greater feel for the system's characteristics and as a team it's enabled us to become more proactive in preventing potential issues. Also, it's a great talking point that helps increase our project's exposure to other teams as they pass by.

from: https://serverfault.com/questions/431981/monitor-a-web-service-hosted-at-http-url/433758#433758