Iteration 47: Reprioritising cards on the Kanban board

The development team (me) was a bit light on resource this fortnight, as I've been getting ready to move house!

The vast majority of my time (when I wasn't packing boxes) was spent fixing bugs, but (in response to a customer's request) I did ship one new feature – Planner's Markdown now supports tabular data. You can find out more on the Markdown help page.

Bug fixes

I like to fix bugs quickly, soon after they're discovered. Letting your bugs pile up can:

  • Give customers the impression that your app isn't a high quality product.
  • Require you to spend (waste) time explaining to your customers why things didn't quite work as they expected.
  • Depress your team – nobody likes having a bunch of unfixed bugs filed against their code, or spending the day "bug fixing".

I fixed a few minor bugs this iteration, and one big one.

Planner had been confusing a small number of people for a few weeks, but I hadn't felt able to prioritise the fix.

For reasons that I probably shouldn't go into (it's hard to explain, and not particularly interesting) the only place you could prioritise your cards was on the Planning page.

On the Planning page cards are laid out in a grid, with the highest priority card at the top left, the lowest at the bottom right. By picking a card up and dragging it to a new position in the grid, you could reprioritise it.

When you viewed the same cards on the Current Iteration page (which arranges the cards in columns - "To Do", "In Progress", etc) you could drag them between the columns. It also seemed as though you could re-prioritise cards by dragging them up and down within their columns.

For complicated technical reasons, you couldn't. Worse still, it had never occurred to me that people would actually want to do it (I always re-order my cards on the Planning page). I was blissfully unaware that people expected it to work.

It seems so obvious now, but this is why usability testing is so important. As designers and developers we don't think about our products in quite the same way that our customers do.

Unfortunately, solving it properly (I didn't want to hack something together quickly) was a big job. This meant I had to prioritise it accordingly – fixing it would delay the arrival of some important new features.

This iteration, I set aside the time to fix it.

Retrospective

I didn't deliver that much this fortnight, partly due to my impending house move, and partly due to some unexpected complexity in this bug fix.

My velocity was 1.75. To put that in context, I've had an average velocity of 3 over the three previous iterations.

About the author

Graham Ashton

Graham Ashton is an experienced agile team leader and project manager, and the founder of Agile Planner. You can follow him at @grahamashton on Twitter.