A couple of weeks ago, I was doing an evaluation of the many Agile Lifecycle management tools in the market for a customer of mine. I was pleasantly surprised to see the various options that an organization would have when they are looking for one.

Before we go further, let us define it. An Agile Lifecycle Management (ALM) tool is one which helps to manage your company’s Agile product development by providing a way to manage requirements, day to day work and progress reporting.

The first question that first comes to mind is “Do we need a tool to manage Agile product development?”
Well, if your team, your product owner and other interested stakeholders are co-located, there definitely is no need for an Agile Lifecycle management tool. A whiteboard, sticky notes, a chart paper for the burndown and a dedicated scrum master who keeps all this in good condition is sufficient enough. However, in today’s corporate world, the distributed product development scenario is one where a team, its product owner, other stakeholders and sometimes the Scrum Master are spread in different geographical locations across the world. For all such distributed product development environments, there definitely is a need for an ALM tool.

The tools that I have evaluated during this period are Scrum Works, Rally, Pivotal Tracker, Green Hopper (from Jira), OnTime, Version One, Team Pulse and a couple of others. From the experience of evaluating these tools, I came across some features that are must-haves and some that are nice to have.

First, the must have features.

• Learning curve: The tool should be easy to learn and use. It should not need more than 15 – 30 mins of training for the Scrum Master, Product Owner and the team members put together.
• Crisp backlog handling: Provision of a easy to navigate Product Backlog and Sprint backlog. A Release backlog is a bonus.
• User story handling: A provision to capture the User story statement and Acceptance criteria, ability to attach files to user stories, ability to break up user stories into tasks, ability to assign duration for these tasks and for team members to assign to themselves or reassign to another.
• Low overhead for team members: A product development team of heads down people working in a time box of 2 weeks definitely cannot sustain the overhead of a tool that is heavy and tough to use. The ALM tool should take a maximum effort of a couple of mins per day for a team member to report progress.
• Easy reporting: Sprint burndown, Release burndown, Sprint Report, easy access to completed sprints,  a guideline in the Sprint burndown, option to see burndown of story points or task hours.
• Assigning Roles to users: The tool should provide role based access to Scrum Masters, Product Owners and team members with each role being able to perform actions as needed. It should also provide View access to some stakeholders who are just interested to know the progress.
• Logging of each activity done. Self explanatory.
• Ability to pan across the various flavors of Agile. The tool should be usable for teams following timebox based XP / Scrum, OR the flow based Kanban. This is quite important since most companies definitely have one or many projects (typically maintenance and production support based ones) which cannot function within the strict timelines of Scrum / XP and will have to use the flow based Kanban.
• Installation options: Option to install within the firewall on the company’s Intranet OR in the cloud.
• A sandbox environment for trying out something in a controlled environment and then deploying it across the entire organization.
• Evaluation copy: Try before you buy option. This is of advantage both to the ALM company and the product development company.

You definitely would want to have the all of the above features in the ALM tool that you plan to deploy across your organization. Please note that the below features are nice to have and tools that provide them might be costlier than the ones that don’t.

Now, the nice to have features:

• Release planning and reporting: Will be great to have a provision for Release planning and a visual progress of the Release’s story point burndown
• Integration with IDEs like Visual studio, Eclipse so that team members can update their task statuses without even logging into the ALM tool.
• Integration with defect management systems like Bugzilla.
• Notes capturing for a) Sprint review comments, b) Sprint Retrospective comments. c) The daily standup meeting (I am actually not in capturing any notes for the Standup)
• User story types: User stories of type Story, bug, enhancement.
• An online Planning poker system to help point estimation of user stories. This is a very good ‘Nice to Have’ feature.
• Video chat plug-in: A video chat plugin with Skype or oovoo so that meetings can be done with video.
• Easy migration to another tool if the company chooses to move to another tool.
• Platform support: Support across various Operating systems on computers and smart phones.
• Custom reports: Ability to create custom reports by supporting APIs for development.
• Export capabilities of the user stories, tasks, etc into csv, xml or html formats. Let us admit it. Some one or the other will want to export the content into excel and run some magical macros to present graphs and charts to senior management. Why disappoint him?
• An internal bug management system
• Non intrusive upgrades of the ALM software itself.

Okay, I think that I have given you a fair spread of the features that are must and nice to have. Comprehensive tools like Rally provide most of the ‘Nice to Have’ features but is quite expensive on a per user license cost. On the other side of the spectrum, we have tools like Green Hopper and Pivotal Tracker which are robust on basics and do not burn a hole in the pocket. Please do a cost benefit analysis before jumping to buy a tool. I would recommend sticking to the must have features and buying a tool that would give you one or two nice to have features that you would definitely use rather than pay a lot of money on a tool that gives you all the nice to have features which you might never use.

Remember that you are choosing an Agile Lifecycle management tool and you have to prioritize your needs and pick up the right tool similar to the way that an Agile Product manager would prioritize his / her product backlog.