Online Scrum Tools – Part 2 – The Product Backlog

As a follow up to my search for an Online Scrum Board, I thought I'd also document my search for an Online Product Backlog, looking at the different experiences of the two Scrum Teams that I'm part of.


Team 1 - The Googlers

When they started their Scrum "journey" the team wanted a clean slate, discarding the legacy Change Request Application that they were less than enamoured with. Without wanting to initially commit to any specific tool, they started with a Google Spreadsheet that was enhanced by adding a Google Apps Script to generate Story Cards that could be printed to make physical copies.

Good Points

  • The backlog could be edited by any number of concurrent users.
  • The story card generation script worked well and allowed for the stories to be easily printed for use during Sprint Planning (Thanks to the author of this spreadsheet, which I used for the basis of the script).
  • The backlog items could be re-ordered by selecting rows, and dragging them up or down.
  • Google automatically saves all changes, so it's easy to roll back should anything "bad" happen.

Bad Points

  • Editing text (Especially User Stories and Acceptance Criteria) is clunky inside a spreadsheet cell - you have to use shift + Enter to get a carriage return, and that isn't natural behaviour.
  • It helps if the user stories have a unique reference, but assigning a unique ID to a column in the spreadsheet became a bit of a challenge, and we ended up with multiple stories using the same ID.

Conclusion

Whilst the spreadsheet was good for getting up and running quickly and efficiently, after 3-4 sprints the problems mentioned became progressively more annoying and there was a general feeling that there must be a better solution.


Team 2 - The Hangers On

The second team took a slightly different approach - their systems and procedures were tightly integrated with an existing Lotus Notes Change Request Application which had a substantial number of outstanding requests.

The initial decision was therefore to maintain the status quo, with a few small tweaks to the application to add some Scrum specific data such as Story Points, User Stories, Acceptance Criteria etc.

Good Points

  • Nothing new to learn.
  • No data conversion required for existing "stories", as they were already in the application - they just needed the scrum specific data to be entered.
  • A unique reference was always generated for a new entry.

Bad Points

  • Priority of an entry was changed by editing the sequence number of the entry, which was not as "nice" as the drag and drop functionality available in the Google Spreadsheet.
  • The application required a lot of data to be entered when creating a new entry (justification etc). This meant that stories that could have benefited from being broken down were left as they were, because it took too long to create new ones.
  • The application only allowed one user to edit the details at a time, which was not great when collaborating between 2 different geographical locations.

Conclusion

Again, the lack of pain to get up and going was good, but it soon became apparent that the application had many shortcomings, and it was likely to slow us down, probably even more so than the Google Spreadsheet.


Trello to the Rescue

I had previously evaluated Trello for use as a virtual Scrum Board, and even though I loved it, and the excellent Trello Scrum Chrome Extension could assist in tracking story points, it wasn't able to easily record the hours worked/remaining during the Sprint, so I dismissed it and moved on.

I'm not sure what prompted me to reconsider using Trello to manage the Backlog, but as soon as I did, it appeared to be the perfect fit:

  • Easy ordering of backlog items
  • Multiple users can work on the card at the same time.
  • Trello Scrum enables Story Points to be recorded against each card, and totals are displayed at the top of each list. This allows the size of the backlog to be viewed at a glance, and stories can be moved onto new lists to get a feel for what future sprints might look like.
  • Card numbers are automatically allocated.
  • The card format is perfect for Scrum, allowing Acceptance Criteria and any conversation points to be easily recorded in one place.
  • It's free!

We promptly trialled Trello in one team, and discovered that whilst it's not 100% perfect, it is pretty close. The main problems we identified were:

  • There is no guaranteed backup of  your data, so you need to consider some sort of export and backup strategy (I'll detail our solution in a future post).
  • The ordering of backlog items is not that great if you have a list containing a lot of cards - the list bounces around a couple of times if you move around a card that is down at the bottom of the list.

Despite these minor quibbles, the trial went really well, and within a week, we had converted both backlogs to be stored in Trello, and 3 weeks on, everyone is really loving it.

For those that are interested, I've set up a sample board, so take a look - I don't think you'll be disappointed.

Update:  I've added a post that shows how to upload an existing product backlog into Trello.

*** Update 7th November 2013 - If you do import a backlog into Trello, then there is another script available to Pimp Your Trello Card and automatically add Google Docs to your cards, Checklists, Descriptions, or even assign costs to your cards. ***

/
If you found this post informative, enlightening, entertaining, or it's just helped you solve a problem then please feel free to shout me a coffee for my trouble from extensive menu below:
Today's Menu