As well as being an agile coach and scrum trainer, I’ve also dabbled in software development. A few weeks ago, I happened across an idea for a software application and I decided to use scrum to help me to create it. The experience reminded me why the location of the product backlog is so important.

It’s déjà vu all over again

Some weeks ago, I had this idea for a software application. I scribbled some ideas down and convinced myself it had worth. Then I decided to use scrum to help me to create it. It would only be me doing it but I’ve written about personal scrum before and I know it’s do-able.

Physical Scrum Board

I set about writing a product vision. As always, this is hard and most scrum teams will skip it. But I always urge teams to focus on this and I applied myself to the task. After a few hours, I ended up with something I was happy with. Excellent.

Next up, a user story workshop. I used user story mapping to help me and created an outline workflow that I refined over a few days. The result was a set of sticky notes, presented in chronological order, that gave me the full story of the application. This was my initial product backlog. Again, I was really happy with this.

Electronic Scrum Board

I then thought it would be good to share this map with a colleague and get some feedback. She works a couple of hundred miles away from me so I’d need to take my product backlog with me. I could have simply taken my sticky notes. I should have done that. But, I didn’t. Instead, I entered my product backlog into an electronic scrum board.

Why did I do this? Good question. I’d spent hours transcribing my product backlog into the electronic scrum board and had no real reason for doing so. I now had two versions of my product backlog. There was no perceivable benefit and I had been ‘busy’ but not delivered value. The phrase ‘physician, heal thyself’ bounced around inside my head.

My advice to others

In my day job, I advise teams to use physical scrum boards with index cards and sticky notes. My belief is that it’s easier to interact with the product backlog. It’s easy to understand. No learning curve required.

I almost always get push back. Teams prefer to use an electronic scrum board. When asked why, it usually comes down to ‘looking professional’. There’s a belief that index cards and sticky notes on a physical scrum board look unprofessional.

Or, teams have geographically dis-located members and they cannot interact with the board. I’ve had sympathy for this view in the past but, my resolve against it is hardening. Read on to see why.

Don’t do as I do, do as I say

So why, when I was supposedly working in an agile way, did I ignore the advice that I gave others? Good question. I had to introspect on this for a bit.

I had convinced myself that, because I was working on my own, the need for the ‘information radiator’ aspect of a physical scrum board wasn’t required. Therefore, an electronic scrum board was a viable option.

Not only did I then move the product backlog on to an electronic scrum board, I was also updating the tool rather than the physical scrum board.  I realized that I was updating the electronic scrum board because it was easier. Instead of digging out my felt pens and sticky notes, I could simply make an edit on an electronic scrum board, which I had permanently loaded. Cool.

Can’t see the Wood for the Trees

But after working this way for a while, the limitation hit me. I couldn’t see the wood for the trees. I had an excellent view at the product backlog item level but I had lost sight of the overall product. This can have a notable slowing effect on progress.

Once this dawned on me, I set about writing the titles of the product backlog items onto sticky notes and re-creating my user story map. This provided immediate situational awareness and enabled me to identify gaps in my thinking. It also gave me the information I needed to decide on an effective Minimum Viable Product.

There’s an App for that!

Now, at this stage, you may be thinking ‘Surely, there’s an electronic scrum board that does user story mapping’? And you’d be right. There are quite a few. But they all suffer from the same constraint: screen size.

If you’re working on a complex product, you’ll have a lot of product backlog items. Way too many to fit on your computer monitor.  Even if you reduce the size of the items and the size of the screen, you still won’t be able to see everything. That’s why walls and floors are often used.

The Unsurprising Outcome

And so, my own experience has reminded me of the value of physical scrum boards. If anything, I am more convinced than I ever was, that physical scrum boards are the right choice.

Remember earlier when I said that electronic scrum boards were viable options for teams with geographically dis-located members? I no longer believe that to be true. Here’s why:

• Teams with geographically dis-located members are hindered by the inability to interact with each other. Using an electronic scrum board masks the impediment rather than addressing it.
• Whether or not teams are collocated, you still need to have the situational awareness that a physical scrum board can provide.
• Electronic scrum boards dictate the way you work (with them). Physical scrum boards happily bend to your will.
• Working on complex product creation is hard. Why make it harder by having to learn a complicated tool?

Thanks for dropping by. If you enjoyed the article, can I ask a small favour? Please use the buttons below to share it with your friends. Thanks