My team is a mix of content creators, designer, two developers, and a few outside contractors for various things. We have been trying Asana Premium and like it but we are also looking at JIRA Software to see what is a better fit overall. We want a single app to handle tasks related conversations.
I’m curious what software the Asana development team uses for their versioning/sprints. If you use Asana what is the setup and workflow?
2 Likes
I found this on your website with a walk through on the initial setup but are there more details via additional blog or video posts? Or another team that is using Asana for development and explains their workflow in more detail?
1 Like
Hi @briankb,
The article from the Asana guide offers a great outline of common set-ups for Sprints. A couple of other details commonly used amongst Asana customers that might be helpful:
- Use a separate project for a Backlog of everything needed to work on and add it
- Pull tasks from the Backlog project into your current Sprint project as they get approved, scoped and prioritized
- Use custom fields for Priority and Estimated Time within your Backlog and Sprint projects
- Some teams create a new Asana project for every new Sprint, others just use the same Asana project deprecating tasks that did not get completed (or moving to the Backlog / the next Sprint)
- (If you create a new project for every Sprint, be sure to standardize a naming convention)
- If you do Standups as part of your Sprint, use a section at the top of the project for notes and agenda
5 Likes
Just wanted to say @Aisling_Grogan nailed it - this pretty much encompasses how I’ve seen most engineering teams work in Asana.
Company-wide, we set high-level goals (we call these Key Results and try to stay at 2 per team member per 6 months) at the beginning of the Episode (approximately a time-boxed Epic in Scrum terminology). The Key Results tasks are placed into a company-wide project to track them.
Additionally, in Developer Relations, we keep an overarching “big story” project with the key results and our backlog / triage of incoming or reactive “general” work that is off-sprint for our main goals.
In DevRel, we then create a project for each of the Key Results so that we can separately track the progress of each goal (i.e. update each key result project on the “Consider updating your project progress” message). This works well for us, because we are so cross-functional that having just one update story doesn’t actually communicate well for us, so we want stakeholders to be able to track only the work for which that makes sense for them to be involved and cuts down on their noise. Also, in this way, the goal of the episode is to invalidate or deprecate each project, which works great.
At the end of the episode, we use a set of Custom Fields across the company to report the status of each Key Result task, and then a script runs through and generates a report of these: how many did we hit, when were they hit, what did our progress look like, did we reach company-wide goals, and so on.
Everything that’s not company-wide is up to the team leads and project managers to choose as best fits their team; I’ve seen everything from “put it all in one project, and pull in the backlog to a section at the top” to finer-grained project management than I highlighted here. That’s one of the things Asana does well - it aims to be flexible, not proscriptive. You don’t even have to do the company-wide activity here; that’s just how we coordinate our separate teams to sync back up and track company progress.
4 Likes
Thought this might be relevant for this thread - we’ve created an add-on to support agile sprints in Asana. You can learn more and check out the video at Burndown chart for Asana - Screenful Guide for Asana
1 Like
Awesome, must-have addition to Asana if you are managing sprints IMO!
Asana has a super friendly user interface that makes task management far more joyful than other competitors.