As Scrum and other Agile practices gain wider adoption there has been more need for tools to help manage these types of projects. Yes, I know, the Agile Manifesto says to respect “Individuals and Interactions” over “Process and Tools”, but even the purists are seeing that larger scale projects require something more than the prescribed low tech task boards and sticky notes. If used correctly these types of tools can help with your Agile practices.
I constantly see postings on various Agile forums asking what is the best tool to use. There are even several blog posts out there outlining the pros and cons for the various packages currently on the market. I find the choice of which tool to use is very contextual and while you do need to do you research on all the different vendors and offerings, you should really get a good idea of what you want from a tool before you go out looking for one.


For instance: If you are a smaller shop that has been previously using the note card and sticky note approach, you would probably not want to jump into a larger, all encompassing tool at first. A larger shop that is moving from a much more structured approach would tend to want something with more features to give them some of the same abilities they had with their previous toolset. Also, various people (Product Owners, Scrum Masters, developers, testers, stakeholders, etc.) have different expectations of how they will interact with these tools and what they will get out of them.

So I thought I would talk about what functions you would perform in these tools and what to look for while evaluating them:

Product Backlog Maintenance

Argue with me all you want, but managing the Product Backlog is one of the more important jobs in Scrum. If you have a crappy Product Backlog, you will get a crappy product no matter how well the actual practices in the Sprint are performed. So what should we look for in this area?

• User Story Support: User stories are basically the standard way to capture requirements in the Agile world and any tool claiming to be a Agile management tool should allow us to easily record and manage them. This means containing areas for the user story, conditions of acceptance (or How To Demo), acceptance tests, story points, business value, and delivery order at a minimum.
  
• Other Product Backlog Types: While I just stated that User Stories are the primary mechanism for capturing requirements, I do think there should be support for capturing things like technical requirements in the Product Backlog too. Even if I record these non-functional requirements in the same User Story format, I like to have a way to define it as a technical requirement for reporting purposes. It also helps with testing since these types of requirements sometimes do not change the user interaction so there would be no new user acceptance tests, but they often require extensive regression testing of existing functionality. Having a way to separate these types of requirements is helpful to the testers to know what will require new tests to be written.
  
• Batch Entry/Editing: From experience I know that a tool that requires me to open various windows to enter or edit multiple Product Backlog items makes planning meets a laborious process. The best support I have seen for this functionality is the ability to export and import from Excel.
  
• Epic/Theme/Feature Hierarchy Support: When planning a large scale project it is important to see the smaller user stories in their larger context by grouping them as feature sets, which relate to a theme, which originates from an Epic. I’ve heard complaints from management about Product Backlogs with small User Stories are tactical approaches and they want to see things at a strategic level. By rolling the smaller stories up to these various levels you provide that type of view to them.

Sprint Backlog Maintenance

Transparency is a key element of Scrum and keeping up with the tasks in the Sprint Backlog accurately is one of the keys to providing that visibility. While the Product Backlog is managed by a single person normally (the Product Owner) and is not usually touched every day, the Sprint Backlog is managed by the entire Scrum team and should be updated daily (if not several times a day). This makes the nuances to interacting with the Sprint Backlog a little different. Here’s what I look for:

• Easy Access to ‘My’ Tasks: Since we want the team to update their tasks frequently, I need to make it as easy as possible for them to view their open tasks, update the task, and grab another unassigned task. While Virtual Tasks Boards are great for this in the Daily Scrum, I just want to talk about editing the Sprint Backlog items during the rest of the day. The best way to ensure this is to integrate with the tool I use most often, which for a .NET developer like me is Visual Studio. But we cannot forget other team members like testers who may or may not being using the same tool.
  
• Batch Entry/Editing: Once again from experience, when you are adding multiple Sprint Backlog items in a Sprint Planning meeting, having to do it one at a time in a new window for each one is a time suck. Excel is once again a great way to do this so look for export and import from the Sprint Backlog as well as the Product Backlog.
  
• Custom Views: As a Scrum Master you will frequently be looking at the Sprint Backlog for various reasons. Because of this you may want to sort or filter the view differently. Having the ability to create your own views of the Sprint Backlog (and this goes for the Product Backlog too) is essential. For example I use a view that shows me what Sprint Backlog tasks were edited today, yesterday, and three days ago (for Mondays to see what was edited on Friday). Scrum team members can also use this for the ‘My tasks’ functionality I mentioned above.
  
• Product Backlog Linking: Just as a User Story links back to a feature, theme, and/or epic, each Sprint Backlog item should link back to an item in the Product Backlog. This is essential for reporting purposes. On the opposite side of that rule there will be unplanned work that may not tie back to the Product Backlog and I should be able to easily identify these orphaned tasks.

Information Radiators

Alistair Cockburn coined the term ‘Information Radiator’ which he described as a type of display that relays critical and frequently updated project information. Furthermore the display must relay the information in a way that the viewer requires very little effort to gauge its intent. In other words I should be able to walk by and with a glance get an idea of the status of some facet of the project. These are normally displayed in the open where the entire team can see them, but with distributed teams that becomes difficult. Here are some of the features and specific types of Information Radiators to look for:

Types of Information Radiators

• Sprint Burndown Chart: The most useful and common of the Information Radiators is a must have in any tool. Some additional features I have seen in some tools that I liked:
  
  Track Done Burndown: Most burndowns are based on “work hours remaining” which sometimes does not tell the whole story. If you have only 20 hours left across 4 Product Backlog items then it would look like you are doing well, but if there are 5 hours remaining on each Product Backlog item and none of them are done then it can be misleading. A track done report simply reports on the number of Product Backlog items that have been marked as Done versus those Not Done (and sometime it will show In Progress ones differently).
  
  Capacity Trend Line: This is the line that shows you where you will be based on your team’s current capacity based on the number of hours to be worked. It is a good indicator if you have bitten off more than you can chew from the start.
  
  Moving Average Trend Line: This one always threw me for a loop until I understood what it was supposed to show. There a several flavors of this (the most complicated being Linear Regression), but what it boils down to is based the average rate of burndown (positive or negative) from a set portion of history, if you continue at that rate the line shows you where you will be at the end of the Sprint. So if you are entering more Sprint Backlog hours at the beginning of the Sprint than you are burning, this line will slope up because if you kept adding more hours than you took away you would never reach 0 hours. It usually looks this was at the beginning but when we really get cooking and have stopped adding in new tasks, the trend line tips over and we get an idea based on an average of our last few days where we would wind up if we kept that average up. If that does not make sense then read this, which will probably make even less sense!
  
• Product Backlog Burndown Chart: If you have multiple projects each with their own Product Backlog, then the Product Backlog Burndown is a good indicator of how close you are to finishing the entire project. It shows the number of Product Backlog items remaining either over time or by Sprint. If you have a companywide Product Backlog then this has less immediate relevance since if it ever went to 0 then you either reached perfection or went out of business!
  
• Hours/Tasks Breakdown by Team Member: There are several versions of these types of reports but they basically show each team member and how many Sprint Backlog items (or tasks) they have closed, are currently working on, and the hours remaining. It is a quick snap shot to see if someone is falling behind. This should be something you naturally discover during the Daily Scrum if you are doing it right but with larger teams it may not be as obvious.
  
• Bug/Fix Trends: Management loves metrics about bugs: How many bugs did we fix last sprint? How fast are we fixing bugs? What is the breakdown of bugs by testing/user impact? Having some nice graphs and pie charts to show the answers to these questions in an easy to view display makes management happy. It can also help a team quickly identify if they have a code quality issue.
  

Display Options for Information Radiators

As I said before, it is important that Information Radiators be as visible as possible to the entire team. So there are other factors to consider from a tool in this area:

• Multiple Means of Access: If the tool only allows you to look at these charts and reports through the tool itself, then you will have limited options when trying to display them for your entire team to see or offer management a way to view them on demand. Most tools provide these reports via the web which can work for most situations, but the better tools I have seen offer them through something like SQL Reporting Services which has many options of delivery including web, email, and exports to Word/PFD/Excel. This will be especially crucial for a distributed team to all have access to this information.
  
• Rotating Views: Frequently I see companies putting large LCD screens in various places around their buildings to convey information to their employees. This is a great idea for information radiators also. A good tool will allow me to pick and choose different reports to be displayed on a rotating basis on an external monitor making it a very effect way to show everyone the status of our projects.

Customization

One of the reasons the Agile world tends to stay away from management tools is that they may force us to adopt the tools process over the process that is best for our team. So for a Scrum management tool to be effective, it must allow us to customize it to fit our needs. Here are some common customizations:

• Ability to Edit Backlog Fields: There have been many times when implementing Scrum for a client that they have needed to record additional information in the Product and Sprint backlogs. This would require the management tool to allow us to add, edit, and remove fields for backlog items.
  
• Ability to Edit Backlog Workflow: We are used to the standard ‘Not Done’, ‘In Progress’, and ‘Done’ type workflows for Product and Sprint Backlogs, but often teams will want to modify these for things like ‘Ready For Test’, ‘Deferred’, ‘Code Reviewed’, etc. Not only is it nice to be able to change the states, but changing the workflow rules is a nice feature along with it.
  
• Ad Hoc Reporting: When you start using a management tool in the Scrum, a ton of data can be captured. You start to be able to easily track trends like how fast does the team close and ‘In Progress’ task, how often do we add new tasks in the middle of the Sprint, etc. This is very useful information and the ability to pull that data out of the tool and report on it can give your team much more insight in how it is performing.

Integration

Managing backlogs is only one part of the Scrum process. During the Sprint there are tons of activities going on that may use other tools such as unit testing, source control, feature testing, automated builds, etc. The ability to integrate with these tools can add even more power to your management tool in a few ways:

• Linking Source Code to Backlog Items: When you add code to your source control repository, the ability to link it to the appropriate Sprint Backlog task (and through that the corresponding Product Backlog item) gives you even more reporting options. You can quantify the exact codes changes that took place for any given requirement.
  
• Automated Work Item Creation: A common example of this is creating a Sprint Backlog task to after a broken build. If you have setup a continuous integration tool that builds whenever code is checked in or on a scheduled basis, if that build breaks you can have a Sprint Backlog task automatically created to fix the build. You may already have internal software tools for tracking bugs or high level requirements and having the ability to setup some type of synchronization between those tools and your Scrum management tool can help with adoption since it builds upon tools your company has a current investment in.
  
• Linking Test to Backlog Items: Just as with source code, the ability to link unit tests or automated feature tests to Sprint/Product Backlog items helps with stuff like traceability matrices. If management asks the impact of changing a piece of functionality you can easily make the change locally and then run all the linked tests to see what it breaks or ensure it does not break anything. It will also help identify tests to be run for regression testing when changes are made to existing code.

Making the Choice

The functionality above covers the biggest feature sets I can think of, but there are probably others. While most of the mainstream tools out there cover the basics fairly well, the other functionality mentioned above could be the deciding factor over one or the other.

My advice is to think of what is the most important set of features for you team and then examine each of your choices to see which ones fit your criteria the best. To help get you started below are some links to some of the top tools on the market. Happy hunting!

• http://www.versionone.com/
• http://www.rallydev.com/
• http://www.danube.com/
• http://www.xplanner.org/
• http://studios.thoughtworks.com/mingle-agile-project-management
• http://scrumforteamsystem.com
• http://www.scrumdesk.com/