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.
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.
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”. 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.