In a previous entry, we took a look at the dangers of over specification.
Over specification is simply where the client not only tells the developers what needs to be done in great detail but also how and when.
We now know this is not a good strategy for building your products, but then what is?
You guessed it, minimal specification!
A minimal specification consists of the minimal amount of information needed to meaningfully specify the product.
Let us go right ahead and look at some of the tools available to us to employ this methodology.
We have already discussed at length what user stories are in invest in user stories.
In the world of software, user stories are the best thing since sliced bread, maybe even better.
A user story follows the format:
As a [persona]
I want to [do something]
so that I can [derive some value]
This very simple format conveys deep meaning. When well done, everyone understands what value they are offering and to who. This has the virtuous effect of providing a rich backdrop for conversations between developers and clients to take place.
Also, because of its concise nature, there is far less attachment. Which means that if the requirement is no longer valid, it can just be torn up and a new one written up.
We use words so much in our daily lives that at times we forget that they have no real existence, they only point towards concepts.
Truth has nothing to do with words. Truth can be likened to the bright moon in the sky. Words, in this case, can be likened to a finger. The finger can point to the moon's location. However, the finger is not the moon. To look at the moon, it is necessary to gaze beyond the finger, right? ~ Buddhist saying
Words then create a new layer of abstraction over the requirement that is being conveyed.
To mitigate this effect, get down and dirty with the work. Have the client draw what it is they want, they can sketch out the UI views or even mind map how their ideas connect. Do everything you can to break down illusions of agreement.
At iHub, we use pidoco a wireframing tool that anyone can learn to use within minutes. This may be useful for you too if say your clients are remote.
Delegate decisions to developers
Developers routinely resolve ambiguities in requirements before it even bubbles up to the client’s consciousness.
- Will we use InnoDB or MyISAM for our DB?
- Will we first register the use on our newsletter and then send them a welcome email or the reverse?
In a day, such decisions may number in the hundreds. It would simply not be practical to have all of them conveyed first to the client for resolution. Yet as is the nature of our work, a few of those decisions will come to the attention of the client and they may not like the path taken by the developers. In such cases, it is important that the impact of reversing the decision be weighed down soberly.
In this way, development can proceed fast with decisions leaning on “What and Why are we building?” being made by the client and the question of “How are we going to build it?” being made by the development team.
What is your theme?
Almost everything is noise. This simple heuristic applies to everything from the candidates who have applied to a posted position to the tweets showing up on your timeline.
The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes. This law applies to requirements just as much as it applies to land ownership where 80% of the land is owned by 20% of the people or business where 80% of a company’s profits come from 20% of its customers.
In the same way, only 20% of the requirements are going to provide 80% of the value to the customer. You must then focus on this 20%.
A theme provides an easy and intuitive way to do so. They map out the landscape upon which decisions are made.
For example, if the theme of our product is “make it as easy to use as possible”, then a requirement that provides sophisticated ways of modifying the behaviour of the product is de-prioritized.
A theme then gives meaning to minimal specifications by providing them with context. This also has a nice side effect of providing a toe-hold for new team members to understand what the project is all about.
Do you use any minimal specification techniques in your own projects? Talk to me in the comment section below or on my twitter @ jchex