Chapter 8. Refining the specification

 

“In its rough form, a diamond is a lusterless, translucent crystal that resembles a chip of broken glass. For it to be transformed into a jewel, it must be cut into a particular gem shape and then polished, facet by facet.”

Edward Jay Epstein, The Diamond Invention[1]

Collaborative discussion is a great way to build a shared understanding, but that isn’t enough to drive any but the simplest of projects. Unless the team is very small and the project is very short, we need to record this knowledge in a way that doesn’t depend on peoples’ short-term memory.

Taking a photo of the whiteboard after a discussion on key examples is a simple way to capture this knowledge, but the examples are just raw material. Raw examples are like uncut diamonds—very valuable but not nearly as much as in a processed form. Separating real diamonds from rock, polishing them, and breaking them into sizes that are easy to sell increases the value significantly. The same can be said for the key examples we use to illustrate a requirement. They’re a great starting point, but in order to get the most value out of them we have to refine them, polish them to show the key points clearly, and create specifications that teams can use both now and in the future.

An example of a good specification

An example of a bad specification

What to focus on when refining specifications

Refining in practice

Remember

sitemap