Taking design out of the requirements

One of the biggest mistake you can make as a product person is to include in the product requirements technical design decisions.
I picked up this lesson about 4 years ago at a session given by Tom Gilb at the first Agile Testing Days conference. I think this lesson is applicable in all types of development processes but is crucial when you are trying to use an agile process

The Mistake

Here’s an example I recently encountered at a backlog grooming meeting:

We need to have a pipeline of processing stages in order to …

It was the word pipeline was got me going. when you mention a pipeline in a user story. no matter how you turn this around you just decided not only what you want but how you want it built. there is no sane user (that I know) that actually care about pipelines. in fact I would assert that most sane user has no idea what a pipeline is, unless they come from the oil business.

So why is this wrong

First lets be clear there is nothing wrong about doing design. In fact it’s a very crucial step in developing software. The thing is that you don’t want to mix between technical design: how we are going to create this, and the business needs (requirements): what we are going to build. and there are two main reason why you don’t want to mix this:

1. when you use the solution in order to describe the requirements you actually hide the business need. instead of discussing the need you start to discuss how you implement it. this makes business decision like prioritization, exact behavior much more difficult. its especially true if the solution is for some reason marked as an “infrastructure” that will be needed. as a product person how can you give low prioritization to something the technical department just claimed to be an infrastructure? even if that infrastructure was just created to solve a less important business need?
2. you don’t want to kill the team creativity – the moment someone put the solution - pipeline in the story was the moment the team stopped thinking about is this the best they can do. Is pipeline the best way to achieve the need? maybe it is maybe its not. putting a pipeline in the solution will discourage any team from thinking about alternative. After all, they were not asked to solve a problem, they were asked to implement a pipeline. so that’s what they will do.

When you are at the phase in which you design your product translating it into requirements for the development team, try always stay in the problem domain. Let the technical people worry about the solution. Technical design is the exact thing they are trained to do. the minute you start giving them the solution you just wasted a highly priced team and probably took one decision much too early.

Posted in: stories,tips