Please, PLEASE add agile functionality for scrum boards, I can’t wait to switch from Jira to Asana, but Asana really doesn’t fill my needs. No story points, no burndown, no different sprints organization contained in one project (I’ve seen the tutorials, but one project per sprint sounds really uncomfortable for companies that manage multiple projects). The rest of the UX looks great: little to none configuration time needed, that is what I hate about Jira, truly clear UI, no learning curve at all.
Asana just gets short on what I stated before: the ability to manage real scrum projects.
We’ve been slowly moving our team to Agile using Asana. For us it’s working out okay. We use team norms to make sure we use Asana properly given it’s open and doesn’t really force a lot on you. Since you put your post in Product Feedback and you’re not asking for any advice I didn’t want to hijack your thread. But I can offer some insight on what my team has done if you’re interested, just let me know.
1 Like
Thanks @RyanE of course, it would be really helpful and I’d like to know the way you’re working with it.
I’ve read some posts about how different companies are using scrum with Asana, but it just didn’t sound practical or comfortable. It’s kind of like using Trello for that; a tool that is useful, but wasn’t designed for the task.
Yeah, I get it. I’m not saying it’s especially easy, but because we were just getting started and learning as we went, it was possible to justify taking the time to design our projects as we went, determine our team norms (or at least take a shot at them), etc.
Here is a post I made earlier in the week that goes over our board designs (the first one I discuss is for our support people, but our scrum based Project Board is in there too below the support board):
In that post I mention using List projects for planning. These feed into the project board. We do our story development in these boards.
This is a screenshot of a project we’re working on to get our organizational hierarchy (i.e., who reports to who) into our ERP system so we can begin getting better integrations with our other systems:
The main reason I show this is we basically break the project up into 3 sections.
- Epics - Main goals of the project
- Stories - Breaking the Epics down
- Tasks - This is where we move any stories that we feel are manageable and ready for our sprint backlog
The process is we basically go to the individual list projects and begin entering our epics and writing stories as subtasks. If a story feels like it’s still very large, we’ll go back to the epic and start splitting it up more. When we feel a story is the right size for the backlog, we’ll move it into tasks, assign it to our Project Management board (where it lands in the New-In column) and assign story points (we did fibonacci numbers up through 13 as tags, SP:01 - SP:13, and color them from green to red based on size) Our active projects we keep in the blue/purple spectrum).
Our main epic task in the “Org Hierarchy” project:
A task in my current sprint:
A norm we have is DD means definition of done (I think most people call this acceptance criteria - we’re mean and decide when we’ve finished something rather than leaving it to our users given we’re not really developing a project but maintaining and implementing other systems from vendors that we have little control over).
And then all this feeds into our main SCRUM board:
Typically we only have things in New-In when planning, but escalated support issues feed in here too so we can work them into our day-to-day project work. The post I linked above explains the columns.
Because planning meetings in agile is a significant time investment to begin with, we tend to not mind the hassle of adding tasks to multiple projects and putting tags on everything. It actually seems to keep us kind of slowed down and in a thinking mode rather than trying to rush through everything. I have a few gripes about Asana with respect to keyboard shortcuts and screen behavior where focus gets lost and control inconsistencies when assigning projects (1st project vs 2nd project) but it’s all pretty minor given how flexible it all is. If I have to occasionally grab the mouse, I’ll live.
Another thing I should point out is we’re using a free account. Custom variables and dependencies could probably add even more. My team has 3 main people that do most the work. However, we’re a school district with about 5000 employees and 40,000 students, so we’re not small. Most other teams, if they have any work management at all (another issue entirely) use Jira or a helpdesk system that I can’t stand (only because it does not lend itself at all to managing projects). I haven’t had a lot of time to compare and contrast with the teams that use Jira, but the little I have seen they seem to struggle far more with the fact Jira has so much stuff in it and with that they seem to lose the freedom my team has to basically decide how we want to do everything. On a large team I can see how a more structured software package might be desired, but I still feel like any team that works well together can hold themselves to to a higher standard to follow norms instead of having the norms forced upon them.
Look things over. If you have questions on anything, I can expand.
2 Likes
@RyanE Awesome contribution… Thanks so much for sharing to the community how you are using Asana. I am sure this will be useful for many of the community members. I have book marked and am sure I will come back and use snippets of your posts…
1 Like
Thank you @RyanE, great contribution.
It’s a nice workaround; I’ll give it a try.
Meanwhile, I hope the Asana team considers to build in the functionality for this. It would make it a far more complete tool.
1 Like