Previously, I discussed the notion of "Agile Requirements" and this concept is embedded in the Prueba Nokia. There is not a definition of Agile Requirements that is commonly agreed upon, so I now use a standard concept that is better terminology for what is needed. For many applications, particularly web applications, a story only needs notes and acceptance tests on a card or sticky note. For some applications, like mobile applications for physicians, unless a fully formed prototype is acceptable to a carefully selected group of test physicians, end users will refuse to use the application when it is installed in the hospital setting. Therefore, a fully formed enabling specification, with a fully working prototype, needs to be agreed upon before cutting a line of code.Apple uses this routinely which is "Why You Can't Innovate Like Apple." PatientKeeper used this strategy during 2003-2008 which is one of the reasons they were the fastest company-wide set of Scrum teams I have ever seen. I called them "The Future of Scrum" at Agile 2005. Some people said PatientKeeper looked more like Kanban than Scrum so they were also the fastest Kanban teams ever seen. I have always run Kanban inside of Scrum since 1993 since Scrum is Takeuchi and Nonaka's view of lean teams. However, we tried to minimize the Kanban, just as Taiichi Ono did and as Toyota does today.
In 2007, I visited PatientKeepers patent attorneys as our CEO wanted to get a patent on a discovery of a reporting strategy for analyzing physician fee payments that would raise hospital revenue by 30% during the first month of use. I asked the Product Owner to bring along what documentation she had for review by the lawyers. There was a three page Agile Specification. This is a document that Product Owners at PatientKeeper use to describe the global concept of a feature. User stories are developed from this document.
Our goal was to work with the lawyers to understand how much documentation was needed for a patent application. The lawyers pointed out that a patent application is an "enabling specification." This is a legal term that describes a document that allows the average person knowledgeable in the domain to create the feature without having any discussion with the originators of the enabling specification.
The lawyers determined that our Agile Specification of three pages was not an enabling specification. To produce a document that would be approved by the U.S. patent office we would need five pages.
It turns out that an enabling specification is exactly what is needed to maximize the process efficiency of executing a user story. The average process efficiency of teams executing user stories is about 20%. This means a story that takes one ideal day of work takes five calendar days to delivery. Systematic Software Engineering, a CMMI Maturity Level 5 company, has extensive data showing that teams that drive story process efficiency to over 50% will double their velocity systematically for every team. (PatientKeeper was running at 10 times the velocity of our waterfall partner in India.)
The definition of an "enabling specification" is part of U.S. patent law which has been adjudicated extensive by the courts so it is not only a commonly agreed upon concept, you can take your requirements to court and the judge will tell you whether or not they are enabling specifications.
In general, requirements are NOT enabling specifications. On a recent project at a large global company we discovered that hundreds of pages of requirements were not enabling specifications. On the average 60% of what was in the documents was useless to developers. It caused estimates to double in size. Even worse, 10% of what was needed by developers to implement the software was not in the requirements.
The enabling specifications used at PatientKeeper provided a global description of a feature set framed as lightweight user stories with screen shots, business logic, and data structures. The enabling specification was used to generate user stories which then formed the product backlog. The global feature description was updated regularly by the Product Owner team and was a reference to the state of the system that allowed developers to see where the user stories in the product backlog came from.
A user story needs to be a mini-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.
A user story contains a template, notes, acceptance tests, and implies a conversation with the Product Owner. So the conversation may be part of the mini-enabling specification if the conversation is clear before the beginning of a sprint. This can be on a card for a simple application and will be on the order of no more than 3-5 pages even for a complicated mission-critical and life-threatening application like the PatientKeeper Platform.
As the lawyers pointed out, an enabling specification for a major feature needs to be no more than five pages. So all of the documentation needed, including transcribing all the conversations, should be on the order of 3-5 pages for a moderately large feature. This is what I mean by "Agile Specification." I now think "Enabling Specification" is better terminology.
2-231 Obtaining Patent Rights § 2.07[6]
"A patent specification is enabling if it allows a person of ordinary skill in the art to practice the invention without undue experimentation."
See Jay Dratler. Intellectual Property Law: Commerical, Creative, and Industrial Property, Volume 1 for citations.
Spanish 
English 
French