OK, I understand. We’re engineers. We love to fix things, build things, and even fix things that aren’t broken because we can make them better.

In that light, I often find myself warning Scrum teams engaged in backlog grooming (click here for more information) to not try to solve their backlog items before they truly understand what they are and what they mean to your customers. In other words, suppose the team you were on was discussing a new internet auction site. Specifically, you were discussing a backlog item that said that your customer wanted to be informed whenever they were outbid by someone else. It’s natural at this point to start talking about how we might build this capability, but it’s really important at this point to stick with what we’re going to build.

In other words, here are some discussions about the “outbid” item that you would want to hold off discussing until right before or during Sprint Planning:

  • database changes to support the outbid notification function
  • creating a list of modules that will need to be changed to support the outbid notification function
  • hardware changes that might be needed
  • UI changes that might be needed
  • changing the bid function to kick off the email to the outbid user

Now let’s look at a list of topics that we would want to discuss during backlog grooming:

  • How does the user want to be notified? Email? SMS Text? Twitter?  Facebook? Recorded phone call?
  • Do we need to support a different notification mechanism at different times of the day?
  • Is there a limit, after which the customer doesn’t care if they’re outbid?
  • Can the outbid notification automatically reset if our customer bids again?
  • Should the outbid notification include the ability to re0bid at a pre-specified amount above the current bid?
  • Is this an automatic function for every item the customer bids on, or just the ones the customer selects?
  • What if the customer is underage or not in the United States? Does that matter?
  • Do emails require encryption? Do they need to be secure?
  • Will we need to be able to prove that a notification was sent if the customer says we didn’t tell him and the item was lost to someone else? Do we need a disclaimer for those who use it?

As I’m sure you can see, the types of discussions you DON’T want to have until right before the Sprint begins have to do with HOW we are going to build what the Product Owner wants us to build. However, the types of discussions you DO want to have during backlog grooming have to do with functionality. What does the customer want the product to do? How do they want to interact with it? What kind of auditing, security or warranty do we need to have in place?

In the first list, the discussions we don’t want to have too early, we’re talking about solution — how are we going to build it. It’s a very common mistake to make during backlog grooming and it’s tantamount to putting the cart before the horse. In other words, we would we want to discuss how we’re going to build something before we even have a fair idea what it is we want to do? Does the customer want what we’ve suggested? Do they NEED it? Even if they want everything (as usual), what do they need first — can they prioritize? When we go immediately to solution, we take the choices away from the customer and the Product Owner and we begin down a path that often leads to a lot of wasted time.

I always point out to my customers the necessity of staying away from solutions until you’re sure about what your customer and your business wants to do. It’s not unusual, despite those warnings, for Scrum teams to forget and learn the lesson more directly. Case in point — one of my customers recently spent about eight days building new backlog items focused on modifying a fundamental function of an existing product. In essence, they started with a single backlog item that said, “the customer wants the product to support x.” They decided how they would support x and immediately began slicing the initial backlog item into a bunch of smaller items that supported the solution they had devised.

After about ten days of work over as many weeks, the team presented their ideas to a small group of visiting customers. Upon presenting how they proposed to support x, the customers began telling the team that “this wasn’t they wanted at all” and “this solution wouldn’t work for me.” The significant portion of the work done by the team had to be thrown out and done again. Because the team focused on supporting x the way they saw it instead of the ways that a customer might use it, their backlog was based on a faulty premise and was thrown out.

When discussing the outcome of the meeting, the Product Owner said (paraphrasing, of course), “this is the way we always work. Take a problem, create a solution — but before Agile Development, we would have gone right ahead and built it.” He went on, explaining that he was glad that we checked with the customer before any design or coding actually began (he lost only ten days of effort, not man-years of effort should they have gone ahead and built it first), but he now saw clearly that the team should have focused more on what the customer wanted to do, not how they should build it.

We all want to solve problems, that’s what engineers do. Remember, however, that it’s very expense to solve a problem the customer doesn’t have or has but doesn’t care about right now. Make sure you’ve got the right problem BEFORE you attempt to solve it.