Half a year ago or so, one of my teams stopped using Jira for their Sprint Backlog and successfully moved to Miro. Personally, this felt like a mini-milestone, because I’ve had numerous failed attempts before.
In this article, I want to share my experience and why and how the team made the switch.
Before I start, I want to stress that this is about the Sprint Backlog, not the Product Backlog. There are overlapping arguments, but the Product Backlog has a different audience and purpose. The Sprint Backlog is there for the team to manage themselves. It’s for and by the Developers.
How I changed as a Change Agent
First, I want to shortly describe how my tactics changed during the years to get the team to improve (their collaboration practices).
Early in my career, I’ve had the luck of some great experiences working in and with (Scrum) teams. This was the main driver to improve every new environment I got into. Sometimes, I only learned in hindsight why some things worked well, for instance in the discussion of using a physical board or not.
When I started as a Scrum Master, I tried to convince and persuade the teams to use physical tools but failed again and again. My knee-jerk reaction was to collect more arguments (at one point I even had a one-hour Powerpoint, *ouch*) At the same time, I worked hard on my teaching skills, but still no effect.
During the years, I already shifted more towards inspiring instead of convincing, but that still wasn’t enough in this case.
We’re talking about a change in behaviour, which is hard. For any change to be sustainable, the person/team needs to have full ownership. I can explain things from a theoretical perspective, but that’s not the same as feeling it yourself. Knowing is not the same as understanding! (example).
Nowadays, I’m shifting my style more towards experimenting/experiencing, but finding the right balance remains a struggle.
Why Jira was not working for us
It started with the fact that the team missed the Sprint Goal too many times. One of the contributing factors was there was no full transparency on the progress towards the Sprint Goal. The team would not always inspect the progress during the Daily Scrum, missing opportunities to adapt the Sprint Backlog, which would have increased the chances of achieving the Sprint Goal. The burndown in Jira was insufficient, perhaps due to being too many clicks away or because the team didn’t feel ownership.
Physical vs. Digital boards
Before covid, most of my discussions were about choosing between a physical and a digital tool.
Pros Physical Stuff
- Scrum implies team-owned processes rather than tool-owned processes
I’ve experienced many times that the tool’s workflow dictates the teams’ way of working. The team should run the tool, not the other way around. Working with analogue stuff is super simple (rotating, shuffling, marking, annotating, colour coding, etc), you’re bound by your own creativity.
For inspiration, check out these awesome Visualization Examples from Jimmy Janlen. - The focus remains on changing behaviour and the system
Tools can be a major distraction. For instance, there are no reporting features that might reinforce traditional management behaviours. Tools support thinking. When they replace it, you’re in for trouble. - The Product and Sprint backlog are clearly separated
The Product backlog contains items that represent features or improvement work. The Product Owner uses it for tracking product progress, deciding features to create next, and making scope/time/cost trade-offs.
The Sprint Backlog is a plan from the Developers on how they’re going to attempt to achieve the Sprint Goal. It’s only valid for one Sprint. It enables them to take a shared responsibility and manage their own progress and all the in-Sprint work.
Most so-called ‘Agile’ tools integrate the Product and Sprint backlog, which leads to confusion about their purpose. - Physical boards are information radiators
Big, visible information on the wall radiates useful stuff into the room. People walking by look at it and engage with it. When the information is alive and useful, lots of conversations end up on the wall. You don’t need to click and open it (and login etc.); every click is one too many. Transparency increases. When you’re done with an item, you stand up and move the tacit sticky forward. Besides having a euphoric moment of celebrating a ‘done’ item, the whole team is aware of your update. - Physical items promote interactions
Cards and stickies have very limited space, which is a great reminder of the fact they’re only a trigger for a conversation. Usually, they only contain some keywords.
Items in digital tools have unlimited space, so people put a lot of text in there. Written communication is dangerous because it creates the illusion of communication taking place. Ironically, we put stuff in writing to communicate more clearly and to avoid the risk of misunderstanding. But, way too often, the opposite is true. - Decentralized (and energizing) communication
The most boring meetings are centralized, where one person is typing, while the rest is observing. But besides the fact that it’s less fun and engaging, it also has another side-effect, which is the ‘slowness’ of adding new items.
Bas Vodde concluded with one of his teams that it was the root cause of poor team dynamics. The team tries to minimize the amount of time typing in the tool, to cope with the ‘slowness’. This leads to bigger items, which in turn can lead to more individualistic work. When there’s one big item, usually one person works on it. But when you split that into four items, it’s more likely that multiple people will work on it at the same time. Smaller tasks increase the amount of shared work, and therefore team responsibility. With physical items, it’s almost effortless to create many smaller tasks, due to the parallelization, and it creates more interaction and fun!
Overall, transparency increases with physical items.
Transparency, inspection, and adaptation form the core of Scrum.
Digital Tool A vs Digital Tool B
With covid, the discussion shifted. Now, the dilemma is in selecting the right digital tool.
The most common tool is Jira.
I’ve heard many arguments for using Jira like tracking, managing dependencies, status checks, notifications, reporting. But do they really lead to delivering better end-customer outcomes like improved collaboration, better insights, sense of ownership, improved quality?
Jira is brilliant for tracking tasks and bugs etc, but it’s not helpful in the aggregated overview of the workflow. Jira has the tendency to hide internal queues and focuses too much on details. You’ll lose the overview of goals, progress, and bottlenecks.
Be mindful of the tool’s purpose. Jira is an issue tracking tool, but what you really need is a collaboration tool, which is a huge difference!
Mural and Miro are examples of digital whiteboards that enable collaboration. It’s the closest thing to (and admittedly sometimes even better than) using physical whiteboards.
How I paved the way for my team to use Miro for their Sprint Board
I wanted the team to experiment with Miro, so I lowered the threshold to start with this as much as possible and took away some ‘excuses’ beforehand.
- “It’s a new/another tool”
I already used Miro for several exercises, so there was no (or at least a minor) learning curve. - “It costs money, we already pay for Jira”
I already had a paid Miro account, but the rest started with a trial. They had one week to experience all the features. I made sure I had the approval to cover the license fees when the experiment was successful. In conversations with management, I was able to explain that the benefits outweighed the cost. - “We must duplicate stuff”
To prevent the team from typing things twice, I used the Jira Cards plugin, which enables importing Jira tickets as Miro cards. I set it up beforehand, which was quite a struggle.
I asked the team if they were up for an experiment. The team had not much to lose and they said yes!
They started small and began with defining the columns to track the progress of the items. This was a great opportunity for the team to reflect on the flow of work. Incrementally, items were added to the board.
There were some hesitations and for most people, it was outside their comfort zone, but after that week the team saw enough advantages and potential to continue using Miro. Since then, they’ve never looked back. 😊
The current board looks like this:
Things have been added, modified, and removed. It’s very easy to inspect and adapt.
Other ways to use the Jira/Miro integration
We also use the Jira Cards plugin during:
- Refinement sessions
Having the cards in Miro enables smaller groups to pull in items and refine in parallel. PS: The plugin syncs two ways, but we hardly ever modify the data in the Jira cards because the editor has a poor experience. - Sprint Planning
The Product Owner makes sure the Product Backlog is properly ordered and then someone imports the top items as Jira cards (beforehand). The team first discusses and selects the items for the Sprint. In part two, tasks are created using Miro stickies or cards.
Conclusion
Some final thoughts and insights I would like to share:
- I used a combination of inspiring and improving the experimental mindset. Instead of using reasoning why the team should try it, you can also ask what they have to lose.
- Prepare the experiment and remove as many barriers as possible. I was glad I did the tricky setup beforehand, otherwise, the momentum would be gone.
- Having the Sprint Board in Miro increases creativity, fun, transparency, and ownership.
- There are many small advantages (like being able to have multiple avatars on a single task when pairing/mobbing), that combined generate a lot of value.
- Most importantly, we do see improved collaboration and more Sprint Goals being achieved, so it was a successful experiment!
