User Stories Should Be *Negotiable*
by Kelly Waters
User Stories are not a contract. They are not meant to be precise, detailed specifications of a feature. They should not be fixed in stone.I recently quoted the 'Invest' acronym as a way to remember and assess what makes a good User Story.
The *N* in 'Invest' stands for Negotiable.
A User Story is a reminder. A reminder to have a conversation about a feature. A reminder to collaborate in order to understand the details just in time for the feature to be developed. Notes can be made on the User Story Card as details are captured and clarified.
A User Story should have sufficient information to capture the essence of a feature without requiring too much collaboration for the basics.
However, a User Story should not contain too much detail. Too much information can imply that the User Story is complete and precise.
So much more information can be gained from a conversation because of the rich, two-way nature of a verbal exchange. Too much information on a User Story can cause people not to collaborate, believing they already know everything they need to. Then you lose out. You lose out on the advantages of combining a written reminder with a verbal, face to face communication.
One of my 10 key principles of agile development is that 'agile requirements are barely sufficient'. Suffient. But barely. No more information than is necessary to proceed with development and testing with reasonable efficiency.
Sometimes a requirement may have been 'specified' in a particular way, and a developer finds that it's awkard to implement. Or that there's an easier alternative. In these cases, a small compromise, or a slight change in approach to the feature, can simplify and speed up the implementation. User Stories should be Negotiable, so no time is wasted when the user or customer's goals can be met an easier way.
So, using the 'Invest' acronym, how does my recent Example of a User Story look in terms of being Negotiable?
Perhaps it's a bit detailed? It implies a particular design approach to the functionality behind the button. Although this is really just a note about a key decision for the design approach that should be adopted; there is no detail on the design of the feature itself.
The visual approach implies a specific screen layout, although it's meant to be a wireframe rather than a screen shot. Personally speaking, as long as people treat it as Negotiable, I think a picture is worth a thousand words and this is well worthwhile.
This example is possibly as detailed as a User Story should really need to get. Certainly I wouldn't expect to see every User Story as detailed as this. Many User Stories could probably be described with less detail. And still be (barely) sufficient.
28 March 2008 02:09
I am unclear how to gauge barely sufficient. From a practical point of view wouldn't you have to shoot a couple of notches above the "barely" line to account for differing perceptions and abilities within the team
Tom Cagley
www.spamcast.net