In this post, in only seven steps, I will try to show how I use with , just by using lists. Here is 

When I start a Scrum Project, the first thing I do is to create a new workspace in 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 

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

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 (PO) conducts a user story workshop with team members and stakeholders. Let's say they produce a 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**

draws the . She can use 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

**Sprint Planning PO decides that the 2 first stories go on sprint #1 ( **SPR1.1 Technical team members produce the . 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

**Daily Scrum At the first daily scrum, a team member says he has completed **task #1 He can get **task #2** andhimself 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

**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
PO moves the remaining story (story #3 and its tasks) from
**SPR1.1** to **SPR1.2**

Finally, Scrum Master updates release burn down chart

Now we are ready to start it over for the next sprint

sprint backlog