Thursday, April 9, 2009

Why As Much As What

When a feature comes into QA for the addition of acceptance criteria, it usually talks about what's going to happen. It describes what the feature is going to do.

Okay, that's nice, but I'm not accepting what it will do.

I'm accepting the solution to the user's problem.

Absolutely we care about what this feature will do. But we also care about why we're implementing this feature. What is the user's need that this is trying to solve? We could build the best car in the world, and it won't help the user get from New York to Paris, thanks to that darned ocean in the middle! Part of our job in reviewing and accepting features is to make sure we're meeting our customer's need, and we can't do that if we don't know what the need is.

A caveat here: we are probably not the best people to be guessing what our customer's needs are. That's where product management (we hope!) really excels. I'm mostly looking for whether there's another thing that will prevent this solution from accomplishing what product management hopes it accomplishes.

For example, if the customer need is "I need to see statistics on how much data we have processed in the last 24 hours", product management may have come up with a new screen in the GUI that shows these stats. This won't help if our customers can't get to the screen thanks to the access control features.

We're looking for the gotchas and the hidden preventers. That's only possible if we know what the net effect is supposed to be, not just how product management is hoping we get there.

So when you look at a feature or a story or whatever you call it, ask yourself not just "how will I know it's done?" but also "how will I know I've solved the real problem?".

1 comment:

  1. Great post. Just today, I was asking about some "specs" for a client project: "Why did we say we would to XYZ for them? What need does it fulfill and what constraints is it constrained by?"

    ReplyDelete