Moving towards a more standardized Agile methodology means finding the suitable tool for our processes.
Asana helped us develop new features and track the issues, but we can see some difficulties in organizing it in the way we want.
The main problems with Asana:
- inability to easily find what the teams are actually working on
- no support for creating and tracking epics (combining multiple stories in order to implement flows and track them across several sprints).
You can mitigate this by creating different projects, add epics as tasks, stories as sub-tasks, then assign these stories to sprints, but you still don’t have any way of seeing a progress report for a certain epic.
We may track the epic status if we create it as a project, but we won’t be able to prioritize it as a whole
- poor reporting – we have only a burn up chart.
- poor overall responsiveness – it freezes and goes down often
- hard to use it in a traditional scrum workflow – does not use or enforce any process
On the other hand, Jira is an older tool created by a well known company (Attlasian) with rich experience in project management software. Attlasian owns Bitbucket also – a service similar to GitHub (Jira integrates well with Bitbucket). Attlasian serves 85 of the Fortune 100.
Jira was designed for teams wanting to enforce a standardized flow.
Main advantages of Jira over Asana:
- more mature product
- built in support for Scrum and Kanban. Also, you can define your own flow by using a visual representation.
- supports epics
- you can prioritize entire product backlog including epics in addition to prioritization of individual epic backlog items
- easily see active sprints
- interactive scrum or Kanban boards (see what’s in progress/done and change status by moving items like you do with the post-its)
- supports estimates using several methods (classic time, issue count, business value, story points)
- advanced agile reporting (sprint burn-down chart, epic burn-down, velocity, cumulative flow diagram, etc)
- can use estimate method (story points for example) to take into account story complexity in reporting
- can track time and let’s you edit remaining time for tasks
- supports working with versions
- supports components (ex: Database, User Interface, etc
- configurable screen types for each type (story, bug)
- configurable fields
- integrates with github to link issues to commits. Also integrates well with other Atlassian tools like Bitbucket, Confluence, Bamboo.
- faster and more reliable
Main advantages of Asana over Jira:
- nicer UI/UX. Asana is a newer product. Every UI interaction is quicker: assign, add labels, comments, upload file, change state, set due dates, add followers, etc.
- more flexible. Does not impose any flow. This can be either a plus or a minus, depending on what we want.
- who is doing the issues more visible, and easier retrieval of the list of items assigned to a person
As a personal impression, It feels very natural to work in Asana, and I have a hard time finding my way in Jira. If I could combine the Asana ease of use and Jira flows and reporting I would say that would be a good choice. For now it seems we need to choose from ease of use against better processes.
Coming from a flexible tool like Asana to something more rigid like Jira will mean we definitely need to follow stricter procedures and some frustrations may arise out of this because some may feel that procedures will stand in their way. That’s why a transition from loose procedures to more rigid ones need to be carefully analyzed.
My recommended workflow using Jira:
- Preferably use a single project in order to have a single backlog and prioritize the project from a centralized place
- Use Components to organize related items (Broker Area, Employer Area, etc). Components can have Component Leads: people who are automatically assigned issues with that component. Components add some structure to projects, breaking it up into features, teams, modules, sub-projects, and more. Using components, you can generate reports, collect statistics, display it on dashboards, etc. Project components can be managed only by users who have project administrator permissions. They should have unique names across one project. Nothing prevents users from adding issue to more than one component.
- Use Epics to group related stories and track flows. Epics or complex stories may be re-organized during the backlog refinement meetings
Note: There is no easy way to prioritize epics itself. To accomplish this you need to add a KanBan board and filter only epics. This can be used as a Roadmap or as a ScrumBan bucket.
- Use Labels as the simplest way to categorize items. Anyone can create new labels on the fly while editing an item. All project labels are displayed in the Labels tab of the project as a tag cloud. We can have labels like Production emergency, Feature requests, etc
- Use parallel sprints (this is experimental feature in Jira but our current process uses parallel sprints)
Where to enable this:
- use this workflow
- use this board configuration: