Jai’s Weblog – Tech, Security & Fun…

Tech, Security & Fun…

  • Jaibeer Malik

    Jaibeer Malik
  • View Jaibeer Malik's profile on LinkedIn
  • Subscribe

  • Feedburner

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 32 other followers

  • Archives

  • Categories

  • Stats

    • 412,782
  • Live Traffic

  • Advertisements

Choosing the Right Backlog Management Tool

Posted by Jai on July 19, 2010

Sorry for staying away from the posts for this long, I have been a bit busy with the new assignment and stuff. The future plan is to share some of the learning in recent past regarding how to work out the tooling for Agile teams and lesson learned in the process. How to choose the right tool for the backlog management? What are the different tools available and what are the different factors that come into picture to take such decisions. What are the different ways to decide upon the same? We will also concentrate on some requirements which definitely change from team to team and organization to organization. It is hard to generalize these things and I will try to put some perspective to these things and see what fits best to your requirements.

The Backlog refers to the work to be done in future. Based on the process the team follows, you may need to manage different types of backlog like product backlog, sprint backlog etc. The inputs for the backlog may come from different parties involved in the process of releasing the product. The requirements may come from end users, within the team or from testing team etc. The big challenge is to stream line all this process and integrate these teams for the smooth running. To have a single tool which meets all these requirements and mapping the tools features, suitability, flexibility and maintainability with these requirements is another challenge.

There may be different parties involved in taking decision that which tool we should use and will fit the requirements

  • Development team
  • QA team
  • Design team
  • Project Management
  • Organization level decision makers
  • Outside world based on project requirements

Each party look out for different requirements related to the Agile process and what will fit best for them. How you can proceed with the decision is to look out for the options available for tooling system in the market.

  • Each Organization is more concerned in using the tools which cost less, which help teams in efficient way and for which they need to put less investment in maintenance. People at this level more interested in getting overview of all the running projects, the portfolio management. They would prefer the tool to give them clear and better picture of all the projects.
  • Dev teams more concerned about doing the job and keeping it simple. They are less concerned about the tooling things. The tools should be easy to use and with less burden of maintaining it up to date.
  • QA team is more concerned about proper tracking of the issues in the product the proper process to file, fix and close those. The tool should support proper communication with the dev team to handle the bugs.
  • The project management team is very much concerned of the report that are provided by the tool to keep track of the work and do the milestone planning accordingly. The tool should be able to handle
  • Based on the project requirements, there may be that the actual end custom feedback should be mapped to the tool which on further requirements are integrated with actual backlog system.

The complication with the process of taking such decision increases if you need to take such decision at organization level for many projects working with multiple teams. Sometimes such things become more bureaucratic than actually getting it done.

Each project/team have different requirements. Some of basic requirements we can think of :

  • Automated requirements gathering from end users/outside world
  • Prioritize the requirements
  • Sub set of requirements for iterative/sprint planning
  • Task management for development team
  • Issue tracking for the QA team
  • Reporting for the management team
  • Supporting development process like Agile etc.
  • Portfolio management
  • Handling dependencies properly, minimizing waste
  • etc. etc.

To review the existing tools based on the Tools available, team requirements, process (Choosing right tool for Scrum) , organizational goals, open source tools try,

  • Explore available requirements
  • Check availability of tools in the market
  • Cross check the specific by each team with the available tools
  • Cross the organizational requirements with the tools
  • Filter out the tools which meet the requirements.
  • Final decision with requirements and management team is taken on consensus
Tool/Team Specifications Tool1 Tool2 Tool3 Team1 Team2 Team2 Organizational Requirements etc. etc.
Spec 1 etc. etc.
Spec 2 etc. etc.
Spec 3 etc. etc.
etc. etc.

The spec changes as per the process the team is following, the team structure, the project reporting requirements, organizational costing factors etc.

Personally, I think the tools are just a helping hand in reaching the final goals. It just supports the team in day-to-day activities to reach the higher goals. No tool is perfect in itself but just that which one will fit best to the team requirements.


2 Responses to “Choosing the Right Backlog Management Tool”

  1. […] Posts Choosing the Right Backlog Management ToolHow to set maximum open cursors in oracle?How to set UPA (Unique Particle Attribution) rule […]

  2. Great article, however I think it’s definitely worth noting that there is a real danger that people often think their backlog management tool is going to make them great agile practitioners. In reality, tools can often hinder the agile way by reducing the amount of human interaction and communication which is fundamental to implementing agile effectively. I’d be careful recommending that when you’re looking for an agile tool that you should look to see which products can solve all your problems. I’d be more inclined to say that you should look for the tools that solve your biggest problems and focus on those, and where possible, still rely on human interaction and communication.

    I’m clearly a bit opinionated on the matter as I have been involved in the development of an agile backlog management tool called easyBacklog, and our focus has been entirely on less functionality, focus on the most important tasks, and don’t replace human interaction with technology unless you’re really aiding the process.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: