Sharing statuses on a Jira board is a day-to-day reality for many, or most, digital product teams. Back in the day though, these boards were often physical and lived on the walls of offices: with the TO DO / IN PROGRESS / DONE columns demarcated using pens or tape, and the team’s tasks written on sticky notes.
Earlier this summer, I had a chance to recapture this traditional way of doing things, when I worked on a product launch with Which?.
The pen-and-sticky paper Bug Board came into being for one simple reason. Just this once, the team would be in the same place, our office in Cardiff, rather than mainly working remotely as usual. In all, we were in the office for three days: one for setting up, one for the release, one for immediate aftercare. The picture above shows where the Bug Board ended up at the end of this period - pretty successfully as you can see, given the number of items in the DONE column.
More on how the board came to be, and what I learned from it, is below.
The background
Personally, in a decade or so of experience working in various project manager-ish positions on various product teams, in different sectors, in the office and working from home, working in one or another Agile framework, Jira’s pretty much been a constant presence in my day to day working life.
And not always a welcome presence. I’ve nodded along while reading so many “Jira sucks” posts at this point that it’s easy to forget the app’s fundamental usefulness - as a source of truth for where a team is at along the various phases of getting some code into production. But yes: it’s slow, clunky and can get in our way, especially if the associated workflows and processes are too heavy. An over-complex or poorly-maintained Jira board actively blocks us from understanding each other.
Such shared understanding within teams has never been more important, with the shift in working patterns caused by COVID: if we don’t spend most of their time in the same room - the ‘co-location’ that, before the pandemic, project managers were told was absolutely essential to a team being capital-a Agile - we don’t have so many opportunities to communicate. Online boards, Jira boards, correspondingly become more important to us.
But this Which? launch meant that, for once, most of the team would be together in the same place. Even better, most of the users were also going to be there, as we were launching tools and services that are used by Which? staff - advisers at our call centre, using our CRM system, Salesforce.
Given this unprecedented co-location, we decided to ditch Jira for the launch, and instead track our progress using actual sticky notes on a board on a real-life wall in the actual office. I set it up on the day before the release, and wrote its name on a piece of card at the top: I called it the Bug Board.
What I learned
Here’s what I learned from this strange, unfamiliar yet ultimately very satisfying experience!
It’s a more lightweight process…
The biggest thing I learned in Cardiff is that it’s a great privilege to be in the same room as your end users and the product team while you launch something.
The Which? staff that were our users could talk directly to us about things they found and improvements they wanted, just by wandering over. Also, we on the product team could talk to each other, face to face, about how to make changes in the best way possible. And there were enough hidey-holes and quiet corners in the office to make focus work generally possible. (We exemplified the old, pre-COVID “Caves and Commons” room layout that was once advised by Agile coaches.)
Personally speaking, working from home most of the time has been a total life improver and I wouldn’t ever go back. But in certain special circumstances like a big release, being together in person is unbeatable for getting things done.
And if you are together in person, the main use case for Jira disappears. The far more lightweight process of writing a few words on a sticky and putting it on a board means more time for talking and building!
..and you get things done quickly
One of the absolute worst things about Jira - not to make this too much of a Jira bashing post - is how slow it is. Decades of digital lint have accumulated on there, to the point where even the simple action of loading and transitioning a ticket can take several seconds.
On the Bug Board, you just needed to rip off a sticky, write some words on it and stick it on the wall. Then rip it off and move to the next column when ready. Almost instant, as well as being tangibly satisfying. I noticed that team members almost always took the initiative to move things along the board themselves, and it made me think of all the times I’ve nagged people to update statuses in Jira that had fallen out of date.
This quick action also translated to real benefits. For example, an adviser gave us a change request in the office: to reorder a field in the system to something more logical. We could then put the request on a sticky, huddle with each other on the benefits of the change, prioritise it with the product manager (also in the office) and get it built, tested and deployed, fast.
How would that have worked if we weren’t all there together? Without the instant feedback and lightweight process? Probably the request would have come in as an email, or raised in a (virtual) meeting. If it was raised at all. The ticket may then have been added to a Jira backlog - then maybe talked about in a refinement meeting some days later, then added to the board some days (or weeks) after that. And, after delivering the change, we may have then realised that we wrote the ticket out wrong and didn’t actually do what was needed!
You can tailor the board easily…
The bane of any Jira admin’s life, especially in the Company-Managed project types used by most larger organizations, can be summed up simply: changing anything. Even something as simple as renaming a status or switching a workflow is ludicriously confusing and convoluted - whisper the words “issue type screen scheme” into my ear at a vulnerable moment and I’ll probably start crying.
With a pen and paper board though, all of those problems are sidestepped. We could improvise changes, and in fact changed some of the conventions and rules around the board (grandly known as “policies” in Agile-speak) as we went.
For example we found a bunch of different dot voting stickers in the office, and used them to demarcate the different releases on the board. Later on, we set up a new BACKLOG column that was the stage to TO DO: things that we might do if we got time, but hadn’t definitely been selected for development. In our company-managed Jira, this would have been a nightmare. On the bug board, this just involved putting on another strip of masking tape to mark out the new column.
Once we had the physical backlog in place, our product manager then had the option of clustering thematically-linked or potential duplicate stickies in groups, as well as prioritising from top to bottom. That kind of multi-axis arrangement simply isn’t possible in a simple Jira stack of tickets.
…except its name. Which you should pick carefully.
If I have one regret about using this board, it’s that I called it BUG board. We were a bit of a victim of our own success here - as, in the end, we didn’t have too many bugs following launch. Most of the stickies you can see in the photo above are actually feature improvements not bugs!
I mainly wanted to call it a bug board because I assumed that most of our users were likely to know what a “bug” was. But actually, I was overthinking it - things progressing through columns of a board to DONE is a simple concept even if you’ve never seen it before, so we could have called it whatever we wanted.
Instead, this poor choice of name caused confusion among the product team. At first, some of them were unsure why we were including feature requests and upgrades on a board with that name - and asked, shouldn’t we have a separate board for those?
You’ll love being free from Jira…
Anecdotal feedback from the team, while working on the Bug Board together in the office, helped confirm all those “Jira sucks” posts I linked to above! When I broke the news to the them that we didn’t need to track anything we did together on there, people seemed pretty happy - and as I’ve hopefully explained above, the freedom the change offered gave them a real productivity boost.
I loved the freedom too. Each task or story existed only as a single sentence or few words on a sticky, with no detailed implementation details or acceptance criteria; those were built out by… talking to and trusting each other. Exactly the Agile values that I always hope to help instil in the teams I work with.
This all made me question the hours upon hours we spend in teams on backlog refinement and user story writing. I’m not saying that such activities are unnecessary - but how much of that time is effectively wasted by writing out to-dos that just requires some common sense or a quick conversation from the do-er?
…until you need it again!
I don’t want to suggest that our Jira-free days were also problem-free. We found a particular pinch point came when fixes and improvements needed to be tested before being delivered. We bundled several stickies into each release. But the onsite QA had a tough time keeping track - and resorted to taking a photo of what was ready on the board on her phone so she knew what to test. In Jira, all of that is right there on the screen!
This was obviously less of a problem for the product manager and the users - who were most concerned about adding stuff to the board and tracking work as it was completed - and the engineers - who generally worked on one sticky at a time.
A bigger procedural problem came the day after the release, when most of the users went back to working from home, while the product team remained in the office. We quickly realized that there wasn’t a good way for them to report any issues and improvements remotely, so threw together a Google Sheet and asked them to update it with anything they found. This lead to duplication of work (copying stuff from the Google sheet onto stickies for the Bug Board), and gaps in communication, because it was a faff to keep the Google Sheet and board statuses in sync.
The end result was unnecessary frustration on both sides. Definitely one that I should have thought more deeply about before launch.
And the final bit of grit was thrown up following the release, when we all went back home and all the unfinished items needed to go back into Jira. I took photos of the board, and transferred it all to a Miro canvas using an app that supposedly was able to create virtual Miro stickies from the photo. The actual text that ended up on the virtual board bore little resemblance to what was written on the paper stickies, meaning I had to correct it manually. Then these were bulk-converted into Jira cards and added to the relevant backlogs. This took 90 minutes or so and felt like an overly-convoluted process.
In summary
So the moral of this story is, in certain situations when it’s practically possible to be free of Jira for a time and use a pen-and-sticky-paper board instead, and you have enough people in a room together, it’s 100% worth doing. Even if it’s a pain to go back to normal afterwards.
Of course, these days the use cases for such a board are pretty narrow: it’s only worthwhile when you have a critical mass of people in the same room, working on the same thing. In an age of hybrid working, then, we are not going back to these real-life boards. Jira’s business model is safe - though I personally can’t wait until someone comes up with a more performant and flexible issue tracker to break up its monopolistic hold on the market.
There’s also a more general learning for me, now that I’m back in Jira-land. If I can’t track my teams’ work on a pen-and-paper board, I can think hard about how we can recapture some of that in-person, Bug Board energy in our teams.
I found that energy in all the human contact and conversation, all the working with users, all the responding to change. Sound familiar?