Over the last several months I have been working on several Product Features pertaining to KiSSFLOW . One of the many questions that have been intriguing me is “What constitutes a good Feature Specification?”.
Form Follows Function
I had tried several mediums to communicate Feature Specifications, including Presentation Slides, Detailed Written Documents, Key-Point Document with Designs, and Annotated Designs with Various degrees of Success. What I did eventually learn was that the Effectiveness of a Feature Specification Document was not determined by the medium used to communicate it but by the content actually communicated. Form Follows Function.
Qualities of good Specification
An effective Feature Specification Document contains three qualities. It’s:
Comprehensive
A Good Spec is comprehensive. It lists down all that the Feature expects to accomplish. Particularly it will describe:
- How a Feature Will Appear
The spec should contain design as well as textual explanations of all the visible elements of the Feature. - How it will work
The spec should contain explanations of all the interactions that the Feature will accomplish. - How it will affect the Product
The spec should also specify all the things that will break or change when the new Feature is built. Its seldom possible to build a Feature that is completely independent of all else.
Unambiguous
- Clarity of Goal
One of the primary things the Feature Specification should do is to explain why a Feature is built in the first place. What the goal for the Feature is and more importantly what its Goal will not be. This “Context” is most important for anyone developing the Feature. An engineer who understands the need for a Feature does a much more thorough job than an Engineer who doesn’t. - Clarity in Approach
One more thing that the spec should do is explain why a particular approach is taken to implement the Feature. This forces both the writer of the spec as well as the developer to appreciate the various possible approaches available as well as the relative merits and demerits of them. Knowing this will help developers as well as other stakeholders appreciate why a particular approach was favored over another. - Clarity in Language
Linguists define this as pragmatics. In common terms this is the understanding gained by reading what is written in the Feature Spec based on the “context” that is conveyed or implicitly understood. I have noticed many times that the reason for the disconnect between what is implemented vs what was expected lies in the way the Spec was (Mis)understood.
Future proofed
We have a philosophy here at OrangeScape / KiSSFLOW
“Design for the Future, build for today”
This philosophy does not stop at Engineering alone, but penetrates both design and product. The Feature Specification should be adequately future proofed. A good Spec will always address three things.
- What should be done to have completeness
The Spec should define define everything that needs to be done in order to achieve both Feature Completeness as well as Product Completeness. - What will not be done immediately
Because of resource or technological limitations, or for strategic reasons feature completeness cannot be achieved always. In such cases the Spec should clearly define what absolutely needs to be done and what can be deferred to a future date. We usually strike out contents to tell that we have this in our vision but will not be doing it immediately. - What should be possible in the Future
The Spec should also define what improvement to the scope could be brought into the Feature in the future. This will help engineers architect the product better. - What will never be done in the Future
Finally the Spec should also list down things that we will never want to do with the Feature. Now or ever in the future. These help in putting a hard stop on possible scope creeps.
