Every software product that we build begins with a set of requirements.
Teams or organizations who have utilized traditional requirements documentation efforts such as Product or Business requirements documents (PRD’s or BRD’s) typically have issues with translating their requirements process into user stories. Instead of writing long passages of descriptive requirements that are heavy on the use of ‘the user shall’ we move to a smaller specification document that convey details to a specific individual feature.
What teams fail to realize is that their old requirements documents weren’t all that good at conveying the necessary details that allow teams to delivery their product quickly and with quality. You see evidence of this lack of clarity with the large number of change requests that are raised during waterfall projects. In my pre-Agile years it was not uncommon for a typical 6 month project that I led to have over 100 change requests generated to convey the changing nature of the requirements (business, technical and UX). The Agile manifesto addresses this reality by saying we accept change, why? Because it’s there it will happen, to deny it would be to deny the reality of product development, as we learn more we need to change our approach.
User stories, though small in format, need to have a specific level of detail if a team is to have the ability to accurately estimate and delivery the feature.
The basic User Story:
- Story
- Conversation
- Acceptance Criteria
Can be deceptively simple to those who are just starting
In one organization I worked with as we moved into an Agile process the team looked at the User Story statement as THE requirement. It took awhile to get them to learn that successful teams use the User Story format as a specification and not a loose statement with no context associated with it.
An example of a solid User Story specification would look like this:
Another important thing to note with this format is that the team is also collaboratively building Story acceptance criteria by using Behavior Driven Development (BDD) which directly feeds the test automation frameworks that most Agile teams utilize (Cucumber, Fitnesse, to name a few).
There are other efforts/processes that feed into getting the right amount of detail into the story such as Discovery and Pre-Planning and if these are missed you will not obtain the benefits of this format.
Over the past 5 years, teams I have engaged with, who have used this specific format for developing their User Stories have had a much greater success with both delivering on time and more importantly with higher quality.
At my last organization I asked a Scrum team to utilize this process during the Pre-Planning phase of their project. After the project I learned that the Product Owner had been very worried about the team using precious ‘development’ time to talk through the work and build out the context of the user stories. After the project was completed he could state without reservation that taking the time to build out contextually rich user stories with the team had produced two key results:
- The team delivered on time and with more features than he had originally promised the client.
- When he delivered the demo to the client he had high confidence in the product as it met all of the context that had been build out and there were only 2 minor UI issues that were identified during the 3 iteration project.
Take away – Don’t run before you are ready and get the context right before developing.
Sound Agile 