The problem is what drives our work, it’s what tells us what needs to be able to be solved by what we are building. It closely relates to use case goals and requirements, but also to the more coarse-grained OKR’s.
The problem definition
The problem definition is the explicit written statement of the problem.
[The problem definition is] the gap between the current state and the desired state […]
Coplien 2010, p.67
A good problem definition helps the team:
- Self-organise (agile), by providing a directive by which the team will guide its decisions;
- Focus on the problem at hand and eliminate everything else that does not add value to the problem resolution (lean).
Creating a problem definition
Creating a good problem definition is a very important process because starting with a bad problem definition means that we will be putting time and effort into solving the wrong problem and we will need to put more time and effort to rework the original problem definition and the developed solution. It’s a waste of time and effort.
Lean is based on “a culture of stopping or slowing down to get quality right the first time, to enhance productivity in the long run.
Liker 2004, p.38 in Coplien 2010, p. 69
Putting time and in writing a good problem definition, on the other hand, helps us find bugs in requirements before any solution development work is done, making us exponentially more efficient in the long run.
[…] a bug discovered in a requirements review costs you 70 times less to fix than one discovered in the field.
Boehm 1976 in Coplien 2010, p. 69
The problem definition must be created by the people with the power, ability and knowledge to solve the problem. Those are the problem owners.
The key, in this process, is communication. That is really the big value that opens up possibilities and finds bugs in requirements.
This does not mean, however, that we will be able to create a perfect problem definition that will not need updating and will be written in stone. We need to revisit the problem definition frequently to make sure that both the problem definition is still valid and we have not diverged from it.
Why? Why? Why? Why? Why?
More often than not, the problems that are presented to us are already filtered, adulterated, or even a solution. This is the starting point for a bad problem definition.
To create a good problem definition we must dig deep and find out what is the root cause of the problem given to us, the real problem.
A great technique to find the root cause of[1] fully understand the problem is to ask “why?” five times (Liker 2004, p. 252-254 in Coplien 2010, p. 69). Don’t ask for the problem, ask for the story behind the problem, so you can define the problem yourself.
A good problem definition is:
- written down and shared;
- explicitly defines the current state and the desired state;
- measurable, so we know if and when we achieved it;
- short;
- not over constrained.
[1] Thanks to James Coplien for the correction
@hgraca 