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.
- 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.|
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.