How we shoehorned Agile into Asana

At Osmo Systems, we follow mostly agile methodologies. We use Asana as our work-tracking system, but along the way we’ve run into some snags. Asana is extremely flexible and versatile, but the trade-off is that it’s missing much of the structure that helps support agile development. Those of us coming from Jira have missed the first-class support for things like Sprints, Epics, and Workflow.

However, we’ve slowly found workarounds that I think are worth sharing.

Backlog vs. Kanban

Problem

In Jira, there is one single backlog, and you can switch between:

• a list view of all tickets (including both the current sprint and the backlog)

• a kanban board showing the current sprint’s To Do, In Progress, and Done.

In Asana, each project has to be either a list or a board. So you can’t have both a list view of all your tickets, and a board view of the tickets just in this sprint.

Solution

• Create a single “Scrum” project in Asana and ensure all tickets end up in it

• Add a “Status” dropdown field with: “Backlog”, “Todo”, “In Progress”, “Needs Review”, “Completed”

• Organize the “Scrum” project vertically by this status field, with “Completed” at the top, working down to “Backlog” at the bottom

• At the end of a sprint, copy all the “Completed” tickets into a new “Completed Sprint XX” Project. Pull new tickets from the “Backlog” into “To Do”

A (filtered) view of our “Scrum” project, showing how we organize by the Status field to approximate a Kanban board, and also how we create “Completed Sprint” projects to save records of completed tickets.

Epics vs. Projects

Problem

In Jira, there is a first-class concept of “Epics” for grouping tickets together.

Solution

In Asana, we use Projects to group tickets together into “Epics”. We prefix projects like this with “E:”.

Note: every ticket that is created in an Epic must also be manually added to our “Scrum” project. Sigh. Also, the ordering of tickets in Epics doesn’t translate to the ordering of tickets in the “Scrum” project. Ugh.

Projects prefixed with E: are Epics. We also use Projects for long-lived efforts and for tracking our Sprints. You might also wonder why we prefixed the “!bug” and “!Software feature requests” projects with “!”. Or, for that matter, why those are projects at all instead of tags, which seems more appropriate. Both questions have the same answer: yet another work-around, this time to force those labels to show up first in the task list. Project labels always come before tags, and other than that they are sorted alphabetically.

Reviewer

Problem

In Jira, there is a first-class concept of a “Reviewer”

Solution

In Asana, when we move a ticket to “Needs Review”, we add a “Review” subtask and assign a reviewer. Sometimes the Review subtask describes specific things to review. Sometimes we add multiple different review subtasks with different reviewers.

This is one of the few cases where I prefer the flexibility of our Asana solution to Jira’s more on-the-rails implementation.

An example of how we can assign specific review tasks to specific people.

Swimlanes for Standup

Problem

In Jira, you can organize the Kanban board with per-person swimlanes, making it easy to go through a daily standup.

Solution

During standup, sort the “Scrum” project by Assignee instead of by Status, so that each person can talk through their work.

Why aren’t we just using Jira?

The team voted and Asana won out by a slight margin. Prior Jira-users valued the structure Jira provides around agile development, while prior Asana-users valued the flexibility and fluidity of Asana.

Maybe we will switch someday. Until then, we’ve found workarounds that generally get us where we want to be.