Can we have native Scrum support?

:light_bulb: Tip: When posting a question in the Asana Forum, please try to include:

What you’re trying to do

Implement Scrum, meaning a backlog with sprints and epics and stories and story points.

What you’ve tried so far

We’ve tried the advice here.

https://help.asana.com/s/article/asana-for-agile-and-scrum?language=en_US

What’s not working or confusing

It just doesn’t work. This workaround doesn’t make sense. A sprint board should inherit properties defined in the main project, which doesn’t happen. A task or story should have story points which can be added and aggregated/rolled up to the parent epic and sprint, to figure out velocity and create burndown charts. None of that is possible. Not even with custom fields and formulas. The overhead of trying to manually make it work is too much. The sprint should be a child of the project and closed sprints should appear as part of the parent.

The concepts are just all wrong.

A backlog contains the work to be done, not the sprints, if I’m not mistaken.

A portfolio could contain the backlog and sprint projects, assuming you are at least on the Advanced plan.

Also, story points aren’t a part of Scrum.

Using project templates and/or bundles could solve that. (Bundles being an Enterprise(+) feature.

Velocity and burndown charts also aren’t a part of Scrum.

I do agree the article could probably be improved, but I don’t think it’s useful to add things to “native Scrum support” that aren’t a part of Scrum. Especially since most of these are generally considered dysfunctional.

It seems like you’re a purist. I respect that. So I’ll admit I used the terminology loosely. More in the way that it is commonly applied than strictly adhering to definitions.

Regardless, the most common practice for Scrum teams is to use story points.

It seems as though you’re also quite strict about the phrasing, so I’m not sure of how useful this is, but I’ll admit I could have phrased this better.

A backlog contains the work to be done, not the sprints, if I’m not mistaken.

So, what I meant was I’d like to define a backlog, sprints, sprint backlogs, epics, stories and story points. I didn’t mean that backlogs should contain sprints.

I’ll also concede I should have named the thread other than “Scrum”. Perhaps “Scrum+” or “Scrum and Story points”, or something else. That aside…

Here’s the pain point. Many of these practices (sprints, story points, backlogs) are commonplace for software development teams. We’d like to be able to apply some of those with ease. At the moment we can’t.

I hope that clarifies.

Whilst I’d advise against it - Yeah, I’m definitely a purist :laughing: - I expect this would help you work the way you want to work:

  • Create a backlog project, with a story points custom number field and add that to the field library
  • Create a product portfolio, and add the backlog.
  • Create a sprint project, and add the story points field.
  • Add a burndown chart in the dashboard tab of the project.
  • Also add this sprint project to the portfolio.
  • Add a rollup field to the portfolio, and choose the story points field.
  • Multi-home the backlog items into the relevant sprint.
  • Duplicate the sprint project without the tasks every sprint. (I’d normally advise using a template, but sadly Saved view tabs to be supported in Project templates isn’t a thing yet, and I assume re-creating your dashboard every sprint would be unacceptable.

I’m sure the portfolio dashboard will give you some options to track the story points across sprints, and calculate velocity with a formula.

This is a bit tricky indeed. Scrum seems to have a different meaning when you look at what’s most commonly meant vs what’s in the Scrum guide.

And eventhough you are of course free to pursue whichever way of working you choose, as an improvement professional I feel I should add this context and challenge the sense of adding features to support this out of the box, especially when calling it Scrum.

If you’re open to some more soapbox advice:

  • Have one sprint goal per sprint, and name the sprint project after it.
  • Also make this a milestone, and add all work needed to achieve this as blocking. The idea is to add the minimum amount of tasks needed to achieve the sprint goal. (And don’t go cheating by calling “complete all work in the sprint”. :wink: Make it a meaningful increment of value)
  • Don’t add any work that endangers achieving the sprint goal.
  • Have a custom field at the portfolio level where you track whether the sprint goal was achieved or not.
  • Use the status update feature during/after the daily Scrum to reflect on whether you are making meaningful progress to achieve the Sprint goal. (Which I think is a lot more meaningful than the 3 questions most seem to use)

Because in the end I think it’s more meaningful to be reflecting on whether the team is effective in delivering increments of value than it is reflecting on the velocity compared to the last sprint.

/steps off soapbox

1 Like