The ScrumButt Test (3): Enabling Specifications

The third line in the ScrumButt Test is: “The Sprint starts with an Enabling Specification.”

What does this mean?

The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was “complete”.

On the other hand, too many agile teams are trying to be effective when ‘no one knows what they are supposed to build’.

What is wrong with the old waterfall process? (in my opinion):
too much delay
a pretense that further change (or learning) won’t happen
a magical belief that the customer can really fully understand a spec (I have seen it happen maybe once)
a magical belief that “all the questions are answered by the spec”, when we know that people learn much better in a face-to-face Q&A format
So, what are we advocating in Agile (Scrum) to replace this broken process?

Well, it turns out to be a Goldilocks idea. Some wish to make the team efficient and at the same time know we are learning all the time. Thus, I advocate an Enabling Spec. Not too much, not too little; just right.

What does this mean?

Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) thinks he understands the story (let me assume the team is using User Stories). And thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a half-page or a page or two of diagrams or notes. In doing that, (the Business Analyst in this example) will ask the PO several questions, and finds he doesn’t have the answers yet, so new learning will happen.

The enabling spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.

Who decides what the enabling spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different enabling specs.

Let me be clear. Scrum itself does not require an enabling spec.  I,  (and Jeff Sutherland and others) are recommending an Enabling Spec as a best practice.

Scrum does say “improve your engineering practices” and I (and others ) would suggest an improvement area around “requirements”, and more specifically, one using Enabling Specs.

Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Enabling Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Enabling Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful, or just missing (and needed to be written down). (Answer to a question: Yes, all the Enabling Specs developed so far could be in one document, if the team found that useful.)

I would suggest that about 5% of the team’s total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Enabling Specs for the next Sprint.

Remember we are always learning. Just because something got put in an Enabling Spec does not mean it can’t change (if we now know better). At the same time, an unprofessional attitude about learning (“oh, I’ll just let myself learn about that later”) is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.

{Note: To find our previous posts on The ScrumButt Test, you might search on that term in the Blogger search box at the top of this page. I have 3 earlier posts.}

« « For Quick Decisions, Depend on Deadlines || Creativity and Process » »