= Our Implementation of Scrum in Asana - Feedback? =

I’m aware there are other tools that are built from the ground up to support SCRUM (like MS DevOps) but we found that the user interface, usability, and appearance of Asana far outway the SCRUM tools built into those other tools

I'm sharing our process to stress test it, to see where the biggest gaps are and in the hope that some of our work around might help others who like Asana but are unhappy with their scrum support

For context, we’re a small (15 people) data analytics consulting firm

We use the following components of the SCRUM methodology:
Retrospectives/Sprint Planning
Daily Standups
Task Points
We use the following tools:
Asana (duh) - For tracking the work
Tableau (w a data warehouse) - For reporting on capacity and velocity
A custom Google Chrome extension - for facilitating points tracking &real-time reporting

At a high level we do the following (Screenshots of some of these below):
All tasks are tracked in Asana

We have a project template, that has default tasks for each action. This auto-populates all sprint related tasks for each project

Each sprint gets its own separate project. So, tasks are “multi-homed”. Being in the project they are related to (where they are organized by features/epics) and in the sprint projects, where they are organized into sections by:
Meeting Notes/Todo - Tasks are added here for processing before points are added

Running the Sprint - Tasks related to the sprint, specifically:
Setup sprint
Daily standups
Run Retrospective
Run Sprint Planning
This Sprint - Tasks that are to be completed this sprint

ToDo Today
In Progress
For QA - These are tasks that need to be QAed by an internal team member

Waiting On - These are tasks where we are blocked by an external person

Carried Forward to Next Sprint - At the end of the sprint, any tasks not completed are moved to this column. This helps us for two reasons:
We have a historical picture of what was/wasn’t done in the sprint. (Helpful for client conversations)
It helps us identify tasks that didn’t get completed in Tableau reporting

Each task has a custom “Task Points” field. This field is not numerical and is limited to 1, 2, 4, 6, 8, 16, 32, 64. During sprint planning, any tasks greater than 8 points are broken up into sub-tasks. This is a non-numeric field so that we can set colors associated with each item (the larger the redder) and so that users can’t enter any other numbers in

Our chrome extension does the following for us:
We have a “card marking” option, which helps run daily standups and sprint planning:
Marks cards in Asana that do not have points assigned with a red flag

Marks tasks that haven’t been updated in a few days with a yellow outline

For boards where there are tasks multi-homed in different projects, it allows us to filter for a specific project. This is useful when looking at the board for the current sprint, which may have tasks in it from projects A, B, and C. We can filter that board to show just tasks from project A. (Not sure why this isn’t a core feature of Asana)
Inserts points totals from our custom points field into two places that allow us to better understand how many points are in a project, feature, or epic:
The top of the column in board view

Total points in the view next to the project name

Allows instant sync from Asana into our data warehouse. This is useful as it allows us to sync point totals into our Tableau reports for capacity planning during sprint planning

Finally, we have Tableau reports which give us the following:
Sprint Points per Team - This shows us for each person:
How many points they have committed to in the current sprint (across multiple sprints that they may be part of)
How many points has each person actually completed in the last 4 sprints?
Sprint template with card marking and task points:
Chrome extension menu:
Tableau sprint report:
To operationalize it a bit, each of the rituals is run in the following way:
**Sprint Planning/Retrospective**
We run sprint planning and retrospective together, running previous sprint retrospective first, and then moving on to the planning for the next sprint

**Tasks to prepare for the meeting
Setup a new Asana project for the sprint and for the retrospective

Assign each team member a task to fill out sprint retrospective

**Running Retrospective
We use an asana project for tracking with columns “Didn’t Go Well” and “Went Well”
Everyone enter Went Well / Didn’t Go well if they haven't already
Everyone vote on the items by liking tasks they agree with (we use the Asana thumbs up feature for voting)
Sort by votes, review each item and assign follow up tasks to resolve
**Running Sprint Planning
Go through past sprint project, add any not-complete tasks to the new sprint (keep the task in both sprints for backward tracking)
For each project related to this sprint, open project, check features and epics, and add tasks as necessary to hit committed to milestones

Make sure all tasks have points assigned to them by the person who is doing the task. (use the card marking feature of the chrome extension)
Any tasks that are greater than or equal to 8 points need to be split up

Run a client perspective exercise, think about the goals of the project from the client perspective, what else could we propose that would make the client happier?
Sync asana to the data warehouse using the chrome extension
Use the team sprint dashboard to ensure no-one has overcommitted themselves (see details for link)
**Daily Standups**
These happen each day and are not to last longer than 15 minutes

Agenda for each from the project leads perspective:
[Project Lead] Share screen
Cycle through each person doing:
[sprint updates] Filter current sprint for tasks just the person talking

[sprint updates] What did I get done yesterday?
[sprint updates] What am I planning on doing today?
[sprint updates] What blockers am I facing?
[Project Lead] Go through each item that isn't updated, ask about status, and check how we're tracking against the current sprint

[Project Lead] Ensure that each task has points (using the chrome extension)
This has been working pretty well for us, it is a bit clunky to set up but once you have it up and running, it isn’t too onerous

I’d be curious to hear about how you’re using Asana for SCRUM and if you have any feedback on any of the methods that we’re using

I'm curious about two things:
I noticed that you have individuals point tasks, and also you seem to be breaking down your reports by the individual. I would generally recommend that you have the whole team collaboratively point tasks, and that you focus on team velocity (sum of points / time period) over multiple sprints to calibrate problems

The retros seem kinda thin. Maybe you just didn't explain it a lot, but I would suggest trying a different format like Liked, Learned, Lacked once or twice to see if you get different/better conversations. I also am curious how the follow-up items go? I notice that when there is a lack of appetite to do the follow-up items identified in retro, it's an indicator that there is something off about the retro (maybe it's too focused on generating "action items", or maybe there is inconsistencies in the meaning of voting, e.g. people are curious but it may not actually be that important)
Thanks super helpful, to answer your points:
That makes sense. To add some context, we’re not assessing or rewarding anyone on points completed, but rather using this to understand what is “realistic” to be completed in the next sprint, with the goals being better setting of client expectations and better prioritization/completion of goals

Re measuring on a team basis, the place where we struggle with that is that we have people on multiple teams, on multiple projects, serving multiple clients. I’m aware the ideal is to have a team work on one project at a time, but it isn’t possible at the size of our client projects (relatively small)

Any suggestions or places for further reading with that context in mind?
2. Fair point, we’ve tried “sad mad glad” in the past and the team actually preferred this format. That said, follow ups have generally been good. We are pretty happy with this part of the process

Point 1 though is definitely a place we’ve been looking for improvement. So I’m very curious about any additional thoughts

Thank you!
Can you expand on "this isn’t Scrum (which is not an acronym nor a methodology btw). It’s micro-management. " ?
This is the way I've seen scrum implemented with a scrum master running sprint rituals (standup, retrospectives, planning)

We're a small team and so don't have a dedicated scrum master who can act in that capacity, instead, we have the lead for a given project run it

It primarily used during sprint planning to understand what is a "realistic" amount of work that is to be committed to during the upcoming sprint

By seeing the average pace of the last 4 sprints we can then make prioritization decisions if the team has too many points marked for completion in the next sprint