Asana on Agile Projects

Long time ago I wrote a post proposing the use of Evernote as a virtual story board. In practice, I’ve been using this method myself on some projects, and I liked it for several reasons, mainly because of the great acceptance of Evernote and also because of the higher quality of the documentation I could see at project closing, since the tool makes it easy and quick for everyone to write about user stories, personas, retrospectives, impediments, and so on. However, this method had important issues. To name a few: the Product Owner had to share her user account, reprioritizing was tough, the technical team preferred other tools to manage tasks, etc.

Now I have to say I've changed my mind: Asana is my best option. I use Asana for getting things done, interacting with students and project teams, and even for tracking my children’s homework ;-) and also for agile projects, of course. In agile projects, Asana has always been my first option for sprint backlog virtual boards, but I insisted with Evernote for the other uses. When I used Asana not for agile, I liked Asana for documentation as well. I insisted with Evernote because I could work offline, but this is not a real issue nowadays, isn't it? If I don’t have access to a network wire, then I usually have access to a Wi-Fi network; if not I can always use my mobile Wi-Fi hotspot… In conclusion: I keep a tool for everything related to task management, and this tool is Asana, I don’t need any other one.

In this post I will try to explain how to use Asana on projects under Scrum methodology. If you want to see the example I’ve prepared (as if you were the Scrum Master) then you can go to:

• www.asana.com
• user: jose.barato@pmpeople.es
• password: pmpeople

Let's assume I’m the Product Owner. I’ve created a new Asana workspace named AGILE PROJECT. I’ve invited the Scrum Master, two stakeholders and six team members.

I’ve created a new Asana project named REL1 to contain the product backlog user stories due on November the 16^th (project due date in Asana). The Product Owner has to be the assignee for all of the user stories. To write the size (on story points, for instance), she could annotate this in the story title. Asana makes prioritization simple just moving tasks up and down (you can also use tags to practice MoSCoW method, etc).

Tags in Asana can be used to indicate which functional module belongs a story to. You can filter by tags: for instance, if you click on tag “feature 1” then you get all the stories implementing that feature:

If you filter on project REL1 you can see which of the “feature 1” stories are mandatory (tag “must”):

When performing sprint planning, adding “story 1” to “sprint 1” is just so simple as adding Asana project “sprint 1” to task “story 1”:

In the sprint project you can see which stories are planned for the two weeks. The technical team can decompose stories adding new tasks (i.e. sprint tasks). I think it’s good practice to use Asana sections to group tasks and stories, so that everybody can see the story that the task belongs to:

When performing the daily scrum, technical team members may refer to tasks, annotate or comment impediments, etc. When a team member decides to do a certain task, he can write his name on “assignee”, the due date, and a short description. He can attach documents from his computer, Google Drive, Dropbox, etc. Iteractions with stakeholders keep agile using the field “comments”, better than email. When the task is done, he can check it as “completed” so that any follower can check it in their Asana inbox.

I don’t see any need for the three famous Kanban boards (to-do, in progress, done). You know some task is “to-do” if there is no assignee, “in progress” if assigned but incomplete, and “done” if completed. The technical team can reorder the incomplete tasks moving them up and down according to their priority.

Again, I don’t think it’s necessary to elaborate any information radiator, since Asana has its built-in project burn-up, that can be used as a release burn-up or as a sprint burn-up (counting tasks, not story points or hours):

When performing the sprint review, only completed stories are demonstrated (ground rule: a story is done only if all of its tasks are done). Scrum Master completes a story if stakeholders agree that is done. Otherwise, if they don’t validate the story, the Scrum Master moves the story to the product backlog, just by deleting the sprint project of the story (one click). Stakeholders’ feedback can be annotated while they are talking.

After the demo is finished, the Scrum Master can create another task to annotate the conclusions in the sprint retrospective.

Click here to read the Spanish version of this article

Click the label English to see the other articles written in English