Reading the Spec

A few months back I held a Sprint Retrospective meeting after a fairly successful project release. We were going through the list of what went right and what went wrong when the issue of the Spec came up.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Arul: (slightly guiltly look) Well, we really should have written a better specification.  We just copied the it from Phase I, and it got signed just before we delivered to QA.


Ed: Did anyone read the spec?


John: I checked the HTML prototype a lot, but I didn't even look at the business rules document until after I had coded everything.


Michelle: It's always easier to work from the mockups.


Ed: So no one really used the spec document for anything, and maybe if we had put together a one page document on how we wanted to organize or project directory structure and naming conventions we would have gotten more out of the document.


Arul:  But we have to write a spec.


Ed: Really the spec is just a design document for us to come to a common understanding.  It sounds like we should just move the business rules elements into the HTML prototype since it's the only artifact anyone actually looks at.


Michelle: But the PM won't stand for that they'll crucify us.

Eventually I brought the team around to the idea that a traditional spec document wasn’t required for the project. As always old habits die hard, but we haven’t done any non-HTML spec documents for Phase III and it’s gone fine so far. If the HTML prototype is the one thing the developers find valuable, then the rest of the artifacts are just extra work. Some of the PMs are coming around to the idea as well one of them actually ran around a design document for signatures with one sentence in it, pretty agile.