Scrum is easy, backlogs are hard
How backlogs are like your dog
I was certified as a scrum master more than 10 years ago now. I was taught by two of the big names in Agile land, and I think if asked, they would probably remember me well. I have never been one to easily buy into process as a savior. And for an innovator, skepticism is a necessary characteristic (you see how I made that into a positive? Or at least tried?).
Early on in class they were talking about sprint planning: you take your backlog and work with the product owner to pick what you want to do in the next sprint. (Cue Meatloaf, Paradise by the Dashboard Lights) “Stop right there… I gotta know right now… before we go any further… where did the backlog come from?” It had things like “login page” and “secure checkout” so was presumably for a website. How, I asked, was it created? They gave some vague answer about the product owner working with marketing and other stakeholders. I asked a few follow up questions about things I had experienced as hard to figure out relative to backlog creation. And I was told that wasn’t a topic for this two-day class.
At that point, I pretty much stopped listening. I knew how to run a sprint, it is insanely simple for anyone who presumes to call themselves an engineer and does not require training (IMHO). My broader team (about 100 people) was getting trained in order to scale Scrum. We had about 7 scrum teams going and were struggling with things like how to coordinate dependencies, keeping membership consistent, velocity and estimation, what to do about experts in things like security who were needed everywhere but never for a whole sprint, and so on. (Most of this we realized we had to figure out for ourselves FWIW; the trainers didn’t have answers for any of those questions either).
But as a PM (or “product owner”) my biggest concern was the backlog. Do we put architecture work on it? What about design tasks? Spec work? Unit test development in each item or separate? What about test framework development? Monitoring in each item or separate? Maintenance? Is there a definition of done that works for all these?
What I learned over time, through trying every way under the sun, is that a perfectly factored backlog, especially for complex problems, is hard.
Really hard. If you are struggling with it, then you’re doing things right. I first heard the term backlog “grooming” much later, and I’m not sure how the term came about, but it works for me. Because backlogs are like dogs, they need lots and lots of love and attention.
As with so much of product management, there really are no right answers to the questions I posited above. And yes, I realize my confirming this for you doesn’t do much more than make you feel a little less incompetent (that’s something though, right?). The developers you work with will still insist there is a right way and wonder why you are making it so hard. I can prove this with examples, but I’m trying to keep my blogs 5 minutes or less! If you really want one, leave a comment.
So back to our dog. Let’s call him “Backlog”. At first, he is going to need a ton of attention. You pretty much can’t do anything else but care for him when you first get him. Don’t start little Backlog in Jira! He should start out in a playpen like a google doc or sheet. One that isn’t shared (he could get germs!).
When you feel like you haven’t changed every single entry or drastically modified the ordering in a few days, then move him to something more permanent like Jira. But you’ll still be spending a lot of time with him: turning 1 feature into 5, turning 3 into 1, deciding what you want to track as a backlog item versus is implicit in each item, how you are going to estimate, whether you want a separate place for incoming ideas. You’ll have a bunch of conversations with your team about all this but also try not to overwhelm them with the ambiguity that is your “teen” Backlog. Whether you want to do design sprints or quality sprints or research sprints (I think I might have made that one up) will all impact Backlog as well.
At some point, Backlog will no longer be a puppy and is ready to be fed new items every now and again and get regularly groomed. Grooming is things like refactoring later items to be sprint-size, changing some wording to make it clearer, moving an item from one backlog to another, getting rid of stuff you decided you are probably never going to do, maybe merging a couple things you now realize are essentially the same, and generally making sure everyone is clear about the items that exist. You’ll probably do this every couple weeks or so. Backlog is now a properly raised dog and maybe even gets “service” dog award if your team feels totally bought into the backlog as well, making sprint planning a piece of cake. Congrats! You are the proud owner of a well-factored backlog.
So rest assured if you are wrestling with what to put on your backlog, you are in good company. Cat people have it easier but their products won’t be as good. With care and feeding, a backlog can be a PM’s best friend!
