Choosing a Scrum Tool

By Dan Nicola

Even though one of the four agile core values is “Individuals and interactions over processes and tools”, it comes a time in an Agile software development company’s life when it needs to choose a tool for helping teams work and share their progress to customers.

Don’t get me wrong, it is always better to encourage communication and interactions between the members of a team rather than creating walls between people in the form of procedures they need to follow. Still, once this is understood, tools are also important especially for facilitating transparency in what is going on and maintaining historical data that the teams can use.

This is what we were thinking when we decided to look for a new Scrum tool at MAXCODE early this year. All teams were already using physical boards, cards, sticky notes and markers every day, which work so well because they get people talking to each other, encouraging interaction and collaboration. However, we felt the need for something more. When we started the search, we aimed for a tool with the following characteristics:

  • Easy access for team members, PO and stakeholders alike, with different access levels
  • Facilitates creating and maintaining a Product Backlog, allowing to define stories together with effort estimate in story points, business value and ROI
  • Graphical representation of the Scrum board that would be in sync with the physical board
  • Clear sprint and product burn-down charts

A few of us were involved in this endeavor. I have to admit that over the course of one month I had made more than a dozen trial accounts to various tools we needed to play with. Some of them we even piloted in a sprint from a real project. Although several looked promising, there was always something that did not fit: either the tool was too general, meant not only for Scrum but for any Agile-flavor, either we could not shake the feeling it was something that evolved from an issue tracker or in some occasions the tool was just more complex than it needed to be.

In the end, we came by TFS 2012 from Microsoft, which was in beta version at the time. I think all of us liked it from the start. Simple, minimalistic design and it had all the things we required. We tried it on a couple of projects at first, but in a short time it spread in all our teams. I remember it was sort of a viral effect, when a team saw what it brought to other projects, it immediately wanted to use it as well.

Now we are using it in the entire company, giving access to Product Owners from the customer side so they can work together with the team on the same artifacts. We even have a project Planboard on our website that takes a snapshot of the current week, with planned, ongoing and completed sprints. If customers click on a sprint they end up directly to their project in TFS (password protected of course). Want to see how it looks? Go to Planboard.

Share this article