June 19, 2020

Jira Kills the Sprint Backlog

Jira Kills the Sprint Backlog

 

If you were in my class, you probably remember the exercise, where participants list roles, artifacts and events in Scrum. There is one particular case, that started appearing about 7 years ago. Some groups were unaware that a Product Backlog and a Sprint Backlog were separate artifacts, they just thought there is a "backlog". This keeps popping up from time to time. When I invstigated further, it became clear, that it's a matter of tooling.

Many big project management tools, like Jira, Rally or Version One (and many others) make it effortless to go from one backlog to the other, automatically move undone items into a new Sprint and create upcoming Sprint Backlogs for multiple Sprints. Result?

 

  • Automatic carry-over kills any verification - Do we still need PBIs from last Sprint? We don't check, therefrore we can forget about optimizing value.

  • Product Owner manages work inside the Sprint Backlog - doesn't he have enough to do already? But since he is responsible for the "single backlog" ...

  • The Development Team does not touch the "backlog" - it's the PO that manages the "backlog", so why should we bother?

  • We plan 6-7 Sprints ahead and never verify, because those elements disappear from the "main" backlog (*cough* waterfall *cough*)

  • Definition of Done? Increment? But we have tasks to do in our "backlog"

 

I hope that you can see where problems are. It's not the tool itself, but using its default settings without understanding what the original idea behind it was. There are many Scrum Teams sucessfully using Jira, Version One, Rally and many other work tracking systems. 

Just don't let the tool run your Scrum for you.