Los Hábitos de un Director de Proyectos Eficaz: Scrum with Asana in 7 steps

In this post, in only seven steps, I will try to show how I use Scrum with Asana, just by using lists. Here is a short video in Spanish.

When I start a Scrum Project, the first thing I do is to create a new workspace in Asana named after the project. Then I invite team members to join (usually no more than 9) and some business representatives (no more than 4). In order to reach more stakeholders and keep communication fluent among the team and between team and business people, I create a private channel in Slack.

In Asana I start creating these 6 public projects:

PROJECT MANAGEMENT: For tasks regarding up front planning, reference notes, documentation links, etc.
BACKLOG: For the tasks representing product backlog items (user stories and epics).
REL1: First Release Backlog items (user stories and epics).
SPR1.1: First Sprint Backlog for the first release (technical tasks).
SPR1.2: Second Sprint Backlog for the first release.
REL2: Second Release Backlog list is convenient when moving stories from release #1.

Product Owner is supposed to manage the backlog and the releases lists. Team members are supposed to manage sprint lists.

Now let's see step by step how to use Asana on some key points during the agile project lifecycle.

STEP #1. Product Planning: Product Owner (PO) conducts a user story workshop with team members and stakeholders. Let's say they produce a product backlog with 10 user stories.

When I need to describe a user story I use this template (I can reuse this from a reference task in a private project):

STEP #2. Backlog Grooming: PO regularly runs a backlog grooming meeting one hour a week. This session with the whole team and some stakeholders produces the first 5 user stories prioritized and sized. For simplicity reasons, let’s imagine every story is 10 story points.

STEP #3. Release Planning: PO decides that those 5 user stories go on release #1: They move from BACKLOG to REL1.

Scrum Master draws the release burn down chart. She can use this excel file and produce this picture:

STEP #4. Backlog Grooming (again): PO reprioritizes and resizes the user stories list in the release backlog (REL). She gets help to elaborate better story #1 and story #2.

Note the convenience of writing sizing in brackets for stories (points) and tasks (hours): When you multiselect Asana items, you will see the adding automatically calculated. If you want Asana behave like this, then you need to go to My Profile Settings > Hacks, and check "Add up Numbers in Brackets".

Scrum Master updates release burn down chart.

STEP #5. Sprint Planning: PO decides that the 2 first stories go on sprint #1 (SPR1.1). Technical team members produce the sprint backlog. They break down each story on 5 tasks of 10 ideal hours each one (just an example).

In sprint backlog lists, for traceability reasons, I have sections to represent user stories and their decomposing tasks. Besides, I usually connect those Asana sections with the original user stories they come from in release lists (through a link in the description field).

Scrum Master draws the sprint burn down chart.

STEP #6. Daily Scrum: At the first daily scrum, a team member says he has completed task #1. He can get task #2 and commit himself to get it done in 2 days. Another member of the team says she is working on task #8 and she has 5 hours remaining to get it done today. Scrum Master can recollect all this information in Asana, on the go, changing items on list SPR1.1:

After the daily scrum, Scrum Master updates the sprint burn down chart.

STEP #7. Sprint Review: At the end of the sprint, let's assume the team has completed all tasks except one, remaining 15 ideal work hours. We can imagine this progression until the end of the sprint:

They perform the sprint demo for the completed user story and stakeholders accept and validate (PO completes the item representing story #5 in the release backlog). Release backlog pending stories are visible in REL1: