Sunday, April 29, 2012

Enabling specifications and Scrum


Obtaining a patent

To obtain a patent in the US, one thing you have to do is make a specification:

The specification must include a written description of the invention and of the manner and process of making and using it, and is required to be in such full, clear, concise, and exact terms as to enable any person skilled in the technological area to which the invention pertains, or with which it is most nearly connected, to make and use the same (Specification [Description and Claims]).

In other words, the specification should be complete in the sense that by reading it, people skilled in the subject matter, should be able to make whatever the specification specifies - without needing any further clarification.

Scrum and enabling specifications

Jeff Sutherland, one of the fathers of Scrum, has written that:

requirements are NOT enabling specifications

Why is that? Image that you develop some online service and then think of the requirement "The user should be authenticated to the use the service". Is the requirement a full, clear and concise specification? Or might you have questions like a) how should the user be authenticated (e.g. username/password)? b) when should authentication commence (e.g. at every interaction or perhaps a some gate guarding some parts of the service)? c) should the service automatically log the user out after some period of inactivity? The questions are many and only one person can answer them, the Product Owner.

Jeff Sutherland continues:

A user story must be an enabling specification for agile teams to operate at peak performance. If it is not, there will be the need for continued dialogue with the Product Owner during the sprint to figure out what the story means. This will reduce story process efficiency and cripple velocity.

[T]he documentation needed, including transcribing all the conversations, should be on the order of 3-5 pages for a moderately large feature


All Jeff Sutherland quotes come from: Enabling Specifications: The Key to Building Agile Systems.


Emergent requirement

The above sound good, but isn't Scrum all about emergent requirements and specifications? That is, isn't the nature of software that we can only have a full, clear and concise specification when we are done. The Enabling Specification Scrum pattern says:

Most schedule surprises come from lapses in analysis. Since estimation focuses on what happens within the sprint, it's important to move the uncertainty of analysis outside the sprint — into the Product Owner process. If you don't do this, the developers end doing analysis. That greatly slows velocity, and because the team is not expert in analysis or end-user and market perspectives, the requirements suffer as well.

Therefore: The Product Owner should deliver enabling specifications as a sign that he or she has done due diligence in exploring the requirements space.

The claim is not that the Product Owner alone should do all analysis up front. He can work with the team, other business people, customers and so on. But the analysis has to be done and the product backlog items are the responsibility of the PO.