Does anyone have a good way to better manage the backlog workflow for a scrum project? We took ideas from "Groom You Backlog Like A Boss"
https://www.atlassian.com/blog/jira-software/groom-backlog-like-boss-jira-software
and at least have separated the backlog into "Bugs", "Technical Debt", "Backlog". However, these are for issues that have already been triaged, vetted and approved for development.
What we're looking for is some way to move backlog issues through swim lanes like "Triage", "On Hold", "Actionable", etc. This would help us ensure that the only issues on the sprint backlog are those that are ready for development. We thought about creating a separate "Backlog" Kanban project and then periodically moving "Actionable" issues to the sprint project? The downside of this is that the issue number would change causing a break for anyone wanting to check on the status of the original request.
Any ideas?
Hi Wade,
You can use more than one board in a project, I would suggest using a separate Kanban board as the product backlog and your Scrum board for sprints. Combine that with the triage workflow @Karri Adkins mentions and you;d be set.
You could use the Kanban board to work the issues through the triage, on hold, and actionable swim lanes, your "actionable" status becomes your Sprint backlog, and the Scrum team selects the issues for the next sprint only from the list of actionable issues.
Bugs and Technical Debt sound like issue types to me, and you could work those through the same Kanban/Scrum board swim lanes as the rest of the issues. (And now I'm going to check out that blog post :) )
-Scott
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @Scott Theus and @Karri Adkins, thanks for the quick responses! Now to see what's involved in implementing these ideas. : )
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have had to add a precursor set of status steps in my workflow to account for things like this. All my workflows, no matter what project instance they are under, include a triage workflow. Once they pass through those steps it goes into the backlog for the engineering team. So in essence, there are two self contained workflows. When the ticket is created it starts in the triage workflow, when triage is complete, they push it to the backlog. Not sure if this makes sense, but it has made a world of difference for us.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.