Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at Enabling Specifications: The Key to Building Agile Systems
Previously, I discussed the notion of "Agile Requirements" and this concept is embedded in the Nokia Test. There is not a definition of Agile Requirements that is commonly agreed upon. However, I have found a standard concept that is better terminology for what is needed.
A couple of years ago, 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.
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.
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.
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 enabling specification if the conversation is clear before the beginning of a sprint. 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.
posted by Jeff Sutherland @ 10:29 AM
11 Comments:
Great post Jeff. I'm definitely going to share this with everyone I know.
Many people that look at Agile say that there is no documentation. What you have listed as required for a user story - acceptance criteria et al. - I feel is the documentation that is required for the team to successfully create the value of the story. Having a story as a standalone item means information. We just don't need to have all that detail until close to the time we're getting ready to make it happen, IMO.
Thanks Jeff. This post is realy helpful.
It would be great, if you could give an example of an enabling specification to get a better feeling for the level of details that should be covered ideally.
Indeed this is a great post, especially the quantification of the waste in traditional requirements documents.
I'm curious, though, about the 20% efficiency figure for User Stories, and "1 ideal day takes 5 calendar days to implement". Do you have a reference for that? What about teams that are using Points as their unit of measurement?
Dave Rooney
The Agile Consortium
Hi Jeff, are you suggesting that each user story needs a five-page document to accompany it? What you are describing here sounds like a hand-off, which I feel is at odds with an Agile approach. I might describe this as "small-design up front", which would be different, I think, to emergent design, which is more of a continuous dialog.
My understanding of a user story is that it is indeed intended to generate dialog. Certainly much of that dialog can (and should) take place before the sprint but sometimes it is necessary to have continued dialog throughout the sprint. In fact, I have seen teams move much faster when they do this, AND deliver the right thing at the end.
A PO embedded in the team is a powerful thing.
There is good data on story process efficency in my Give Thanks for Scrum Day presentation. See http://jeffsutherland.com/scrum/2009/11/give-thanks-for-scrum-day.html
My point here is that a large story needs a maximum of five pages to document essential details. Most of these can be a conversation with the Product Owner. However, in certain applications with life threatening implications, teams find that a few things need to be written down to make sure everyone remembers them correctly. Like what dose of this drug will kill a patient and when a physician must be alerted.
Fair enough. No disagreement on that. I agree a team needs to understand what they are undertaking. I use the term "well-formed outcome" (from NLP) which likely means the same thing as "enabling specification".
There are times it is essential to get this in writing, often it is better to talk and confirm as we go. Different contexts dictate different behavior. If I had a web dev team working on a non-life-threatening app I'd be very concerned if they had 5-page specs.
Very interesting concept 'enabling specification' - thanks for presenting this.
One of the few (maybe the only) references I've ever come across that mentions 'transcribing all the conversations'. I like this. Conversations are great and are a cornerstone of the agile approach to collaboration on requirements but people's memories of the conversations can easily diverge. Of course that brings up the whole question of the fidelity of the 'transcribing' process. In some cases a high fidelity 'recording' might be a useful approach (i.e. audio or video), perhaps not for the lawyers but maybe for the team.
Pretty good I will say. By definition "Enabling Specification" would mean enough specification that would enable to the team to start thinking towards producing the desired out put. If something is missing, go add it.
Tobias, I do not believe Jeff is proposing a 4-5 page specs for each story - but mentions about a moderate size feature. The number of pages are for you to decide. As long as it ENABLES, I think it is good enough.
I want to ask about the 'transcribing all the conversations' part. How are we going to do this? I know that one way to capture conversation is to record them but is this something you can freely do and use it later for the purpose of transcription?
Transcribing the conversations for the development team in necessary only to the extent that critical information needs to be captured. The Product Owner determines what to write down based on the development teams questions during an estimation session. Anything the development teams knows need not be documented. For patent applications a little more thought about this is necessary.
Post a Comment
<< Home