Enabling Specifications

I recommend using the ‘Enabling Specification’ practice. This is NOT part of the bare framework of Scrum. But it is a frequently recommended practice. Typically recommended.

This is: Just-enough, just-in-time documentation. Meaning that the implementers in the Scrum Team have enough information to build the user story correctly the first time. Or at least they think they do before the Sprint Planning Meeting.

I am NOT recommending eliminating conversations. In fact, we always want more conversations.  The PO should be available during the Sprint to answer questions ‘immediately.’ (Of course, he/she is not always able to answer them immediately, but that is what we want.)

Jeff Sutherland says this is like patent documentation. An enabling specification.  See the Scrum PLOP, and this blog post. Some call it an Enabling Specification.

When is each Enabling Spec built?  Just-in-time. Just before the sprint in which that user story is built.

Who creates the Enabling Spec?  Well, it is built by the right people, of course. Typically the PO will help, a BA-type person in the Team (if one) helps, a BA or two outside the Team might help, a business stakeholder might help, etc. It depends on the situation.

The PO is ultimately responsible for the quality of the Enabling Specs. The implementers in the Team are the final authority of what should be in them.

So, the Enabling Specs are ‘owned’ by the Product Owner. And then the PO must find the right people to build them. (I think it best to usually think of the Enabling Specs as one-to-one with the user stories.)

What does an Enabling Spec contain?  Well, just what the implementers want and need.  This varies a lot from situation to situation. It depends on the nature of the story, it depends on the memories of the implementers, it depends on what they already know well (please do NOT repeat what they already know well), it depends on their skills and experience, …it depends on many things.

Here are some things that people have wanted an Enabling Spec to include:

• a use case (diagram)
• business rules
• mock-up
• wire frames (I won’t bother to give a fine definition to distinguish a mock-up from a wire frame)
• business flow (often quite similar to a use case)
• date elements (or columns or however you think of the data)
• questions answered (the implementers can ask almost any question — we might write some answers in the Enabling Spec)
• technical issues – decisions or descriptions of some key technical issues. One simple example: ‘The scope is only iOS.’
• data flow diagram
• design issues – Example: if this story will break old design patterns or create new design patterns, talk about it a bit.
• acceptance criteria
• other information, assumptions, or notes

If you can have a conversation and the specific implementers take good notes, and will remember correctly, the information does NOT have to be documented (again) in the Enabling Spec.

And you do not have to cover all the above sections in every Enabling Spec.  You should NOT cover all these things. Pick and choose amongst them, what is most important, most useful to your team and your situation.And for each specific story.

And exactly what to include (or exclude) from the Enabling Spec for your Team will evolve.  The PO is always asking the Team two questions:

• What did this Enabling Spec include that you found useless? (Remove that stuff in the future.)
• What did we leave out in this Enabling Spec? (Start adding that stuff, where appropriate.)

Couple of things to note:

It is more important that the implementers get the information they need quickly than that the Team has an Enabling Spec.

Do not build all the Enabling Specs up-front.  This would be a big waste and a big delay.  Only build Enabling Specs for the stories just about to go into the Sprint.  Are we always correct in guessing ahead of time which stories will go in the next sprint?  No. But it is usually a very good guess.

Is everything defined in the Enabling Spec?  No. Only the essential stuff.  Expect some questions to be raised during the Sprint and answered quickly.  If the PO is less available or cannot answer quickly, then maybe the Enabling Specs are fuller?  If the PO is available and can answer quickly, then the Enabling Specs are probably smaller.

Am I ‘successful’ if I just ‘complete’ the Enabling Spec?  No!  The software (product) must be truly useful. An implementer does not have ‘CYA’ simply by ‘doing’ the Enabling Spec. The real test is real progress in satisfying the customer.  The Enabling Spec is only a means to that end.

How big are they?  That varies of course.  How big do you draw? (They are largely pictures or diagrams.)  Probably a whole enabling spec is slightly smaller than it should be. (smile)  Half a page. 1 page. 2 pages.  Something like that.  And that is based in part on the assumption of about 8 stories in a 2 week Sprint.

Can this help you?  Yes.  How much it will help will partly be based on how much the Team is ‘spinning’ on the requirements.  Sometimes the spinning is clear and obvious, and sometimes the spinning is hidden.

 

« « The Team is primary || Achieving the Goal of a Retrospective » »