Using Miro to build an information radiator for your remote team

When my team worked from the same office in ‘the before times’ we used to have an ‘information radiator’ whiteboard that we used to track the progress of our tickets, highlight any blockers and keep reminders for the team of the actions from our retrospectives.

After the pandemic hit and we moved to remote working my team became more dispersed and while this has given us more flexibility as a team it has made it harder to keep track of things because of the tools we use.

We use Jira for managing our work items and although Atlassian have made strides in making it easier to create a view of the work items usable for a stand-up we’ve always had to fight the rigid structure of Jira to add that supplemental information we used to have on our whiteboard.

In order to keep track of the actions that came out of our retrospectives we would create issues in the sprint that would sit at the bottom of the sprint board as a reminder to get updates on how we’re progressing against them and if an action wasn’t completed then we’d roll it over to the new sprint.

Over time this approach led to a messy backlog and when our team grew, in order to hit a deadline, the Jira sprint board we used in our stand-ups would often become so hard to navigate due to the number of sub-tasks being tracked under a story and the person running the stand-up having a small screen.

The stories in the sprint board can be collapsed so this helped to some degree but there were issues where the active story would have a fixed position and overlap the story underneath when the screen was scrolled that sometimes people couldn’t find their bearings.

Additionally, because of the team size increase we struggled to keep the stand-ups short and snappy. This was due to the context switching we encountered where the Jira sprint board didn’t group stories the way the team would, so we’d have to create ways to improve this manually but it was never intuitive enough to not waste time.

Eventually it got so bad that the issue was raised in one of our retrospectives and that’s when I started looking for a way to bring back our old information radiator approach but for our new remote-first world.

Building an information radiator in Miro

Miro felt like the best choice for creating an information radiator as it’s freeform nature meant that we could experiment with different formats until we found one that works and we were already using it within the teams for retrospectives so everyone had access.

Additionally, the team I lead has access to the enterprise version of Miro and we have the Jira integration set up so we can easily create cards on the Miro board from the Jira tickets we’re working with.

This functionality isn’t available in the free version of Miro but it’s easy enough to reproduce some of the features using the standard card object so I’ve done that for my examples.

The information that makes up your information radiator is very subjective to the team’s needs. For my team we wanted the following:

• The work items we’re currently working on, grouped by the workstreams we’ve created to tackle each area of the product
• Retrospective actions we want to complete during the sprint
• Reminders for the team such as scheduled maintance of pipelines, mandatory reviewers to assign when working in specific repos and other things that indirectly impact our work
• Known defects that we’ve found so we don’t create duplicate bugs

This would allow our stand-ups to focus updates on an entire workstream before moving onto the next one and then at the end of the updates address any actions from the retrospectives. The reminders and defects supplement this by making the board a ‘one-stop-shop’ for all things related to our work, exactly what an information radiator should offer.

Continuous Improvement

The initial trial of the information radiator approach returned a minimal speed improvement for the updates given by the members of the team because we were still asking each person to give an update on their ticket as we would when we used Jira.

Miro however isn’t strictly structured like Jira, it’s a collaboration platform so after a couple of days of the new approach we started to make use of the asynchronous communication functionality that Miro gave us, such as sticky notes.

Sticky notes in Miro can contain text, tags, emojis, be assigned colours and have comments. This functionality makes it really easy to convey a whole range of information just by laying a sticky note on top of another element on the board such as a Jira ticket.

We started by using the sticky notes to give a summary of the workstream’s ‘health’ by laying out the stages the work goes through and using a red-amber-green rating for each stage to indicate where there are points to discuss.

The team members on that workstream would then update the colours when they first joined stand-up and that meant that when it was their turn for an update the conversation was already focused in on those issues instead of the usual pre-amble they would have to give.

Later as the work we had to do became more granualar we moved to adding a sticky to the individual work items on the board, using the same colouring system but adding text that represented our update. This meant that we could focus only on the amber and red stickies and doing so saved a lot of time.

Building a shared understanding of the work

After a couple of weeks using the Miro based information radiator we started to identify another part of our team’s streaming approach that was made more difficult by the rigidity of Jira — planning which workstream would tackle which set of work and who in that work stream may be best placed to complete certain work items.

There’s no means to associated a group of developers with a ticket in Jira as there’s a one-to-one relationship but in Miro we could create a basic kanban board with each column being an area of work and add the stories in that area to the column.

We could then use sticky notes to add the names of those in a work stream above the column and put the names of team members on stories that we’d like to work on a story.

Having this board right next to the current work made it really easy to provide a context to the team members of what was coming up and created a transparent planning mechanism that allowed the team to get involved if they had feedback on the plan (we had one team member ask to move onto a different stream because it was in an area of interest to them).

How the information radiator has helped the team

The biggest improvement we’ve seen from the information radiator approach is that the time we spend in stand-ups has been at least halved. We’ve dropped from 30 minutes to 10–15 minutes and I think this is mostly thanks to the ability for team members to prepare their update asynchronously.

Our Jira backlog is now clearer where we don’t have all those pointless (in both senses of that word) retro action work items hanging around and that’s had a morale boosting impact as the list of stories to work on looks smaller without all that bloat.

Having a transparent planning board has made it easier to for the team members to engage with the programme of work as it feels less prescriptive and more like we’re collaborating on how to solve a problem.

Moving our stand-ups to Miro has had a really positive impact on the team and if you have a means to attempt building an information radiator in a collaborative tool such as Miro I highly recommend it.