Even Backlogs Need Grooming

Written By John Sonmez

Imagine this common scenario if you will.

One of your friends calls you up and says:

“Hey, would you mind helping me move on Saturday, I am getting 4 or 5 people together and we are going to move my stuff to my new house?”

You of course reply:

“Sure I can help, what time do you want me to be there?”

“We are starting at 10:00 AM sharp!”

You might have guessed what is going to happen next.  You show up at your friends house expecting that everything is nicely packed in boxes and that you are just going to move some boxes and furniture into a U-Haul, but instead what you see is this:

messy

Seriously?

He couldn’t have cleaned up the house and at least put the stuff in boxes before having 5 people show up at his house to move stuff?

So what should have been a 2 hour jobs turns into a 2 day ordeal as you and 4 other friends sit around waiting for moving friend to pack up his stuff so that you can put it in the truck.

All 5 of you can’t actually help with the packing of stuff and the throwing out of garbage because there is only one person who knows what is trash and what things need to go in what boxes.

If your friend would have cleaned up the trash and packed up everything in boxes before he had the 5 of you come over and help, things would have gone much much faster!

Your backlog list is your apartment

The same kind of thing happens when you call up 5 of your developer and QA
”buddies” and ask them to get some work done for a sprint.

If the team is trying to sort out what needs to be done, what is trash, and what things need to go in what boxes, they are going to be much slower at actually getting the work done.

You see, your list of un-groomed backlogs is not unlike a hobo.  Often times it could use a good wash and a proper shave.

hobo

When I am talking about backlog grooming here, I am not even talking about having a planning meeting, where you plan what you will do next.

Angela Druckman has a good description of a Grooming Session.

The idea is that periodically you groom the top x% of your backlogs so that they are in nice clean boxes ready to be worked on when the team picks them up.

The important thing here is that this is a team activity, everyone should be involved with backlog grooming.  The business really owns the backlogs in most cases though, so they should be directing the team as to which things go in which boxes so to speak.

What about just in time backlog grooming?

Why work on a backlog until the very last responsible minute?

Good question.

For the answer I point you back to the moving scenario I started this post with.

The reason why it is so inefficient for your friend to have everyone come over and try to move him before he has packed up everything and gotten rid of the trash is that you end up having a large amount of idle time waiting on one person.

Think about when happens when a team of 8 developers starts working on backlogs for an iteration at the same time.

If all of the backlogs are not “groomed”, but instead are a scattered mess of mismatched sizes and parts, each developer is going to have to talk to perhaps the same business person about the backlog that developer is working on.

What happens when this business person is out of the office?

What happens when this business person is trying to field questions from 8 developers?

What happens when there is a turn around time to get back to the developers on questions about the backlog?

Now contrast this with the scenario where all the backlogs that are going to be worked on in an iteration are nicely packaged in neat little boxes.

The backlogs may not contain all the technical details of what is going to be implemented, but they are broken down to small bite size pieces that are fairly well understood by the team.

In this scenario the team is going to be able to pick up the backlogs and start going to work.  Sure they will still have to ask the business questions about the backlog, but the kind of questions being asked change fundamentally.

Contrast this kind of question:

So what exactly is this backlog about?  What kind of things do we want to build to report on this data?

To this kind of question:

As we discussed previously and I see in the backlog, we are creating a custom report for this customer.  I also see that we had defined what this column A should do.  Should I be using calculation X or calculation Y to compute this column?

The first kind of question is better answered in a bigger meeting with all the right people.  To answer the first kind of question might require some research.  The first kind of question would hold up the completion of a backlog because it is not easily answered.  It requires thought and perhaps asking other people, talking to the customer, etc.

The 2nd kind of question is specific.  This is something that can be figured out usually by a single person.  Most importantly it does not hold up the work.  Developers can continue implementing parts of a solution and put in the algorithm for computing some value later.