Jira Atlassian is a great ALM tool for managing your Agile environment. It provides a friendly work space for Agile teams, and have some informative out of the box reports that allow teams to easily apply root cause analysis. In the program level, there are several easy ways to achieve aggregated data reports and epic progress boards. The relatively new Jira portfolio also has some interesting features that enables larger organizations to manage their program, including shared planning, shared releases, progress and mitigation plans. Visiting many organizations that use Jira as their main tool for their Agile environment, I decided to summarize 5 common pitfalls it is best to avoid.
- Less is more, avoid heavy configuration Agile is about teams that work together with trust and common mission. Therefore the workflow configured should be as simple and as short as possible to reflect lean value stream rather than handoffs.
- Don’t work for Jira, let it work for you Avoid complex issue cards that are full of information. Always ask why do you need this data and retrospect its benefit over time. Otherwise it’s just another field the team needs to add and the daily overhead is bigger than the value.
- Work in a trusting environment, don’t limit the work for specific role Some organizations set restrictions in the workflow for specific roles. For example – only QA/PO can move a story to done. Such configuration usually is a manifestation of mistrust from management and annoys the team on a daily basis when trying to keep Jira up to date.
- Focus on team deliveries, not on personal tasks Sub-tasks should help the team align about the work to be done towards the delivery of an end to end story. It is not meant for leaders to micromanage individual utilization. Teams should avoid estimating sub-tasks and log work on task progress. The burndown chart that lean on “log work” is misleading and shifts the team focus from the actual deliveries.
- Use the tool wisely to gain its benefits Jira has some great out of the box reports that are based on data the team should update. It would be a shame not to use them due to inattentiveness. For example: – Estimate all stories and drag them into the sprint container before starting the sprint to create a reliable velocity and sprint report – Update the story status in addition to the sub-tasks to gain real visibility on WIP and progress