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.
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.
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.
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".
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).
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:
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:
Now we are ready to start it over for the next sprint.