Whether working on Agile, Scrum or Waterfall projects, it’s really important to remember that user stories and business requirements should only serve the purpose of reminding everyone on the team of conversations and a shared understanding.
Many of us have been in the situation, especially when working on traditional waterfall projects where the requirements are looked at as a contract. Sometimes this really is the situation, however, if you want to make sure that the business gets what they want, it is imperative that the developers really understand the purpose of the requirement.
An Agile requirements techniques that I have seen really improve “shared understanding” and quality of conversations is to write requirements as simple user stories. Mike Cohn, who coined the term User Stories, encourage us to write requirements in the form of
“As a <user>, I want <goal>, so that I can <goal/value>.”
Identifying the user helps in writing user centric requirements and the “so what” helps encourage discussions and makes sure that everyone really understands the purpose of the requirement and value to the business.
An example;
“As a caseworker, I can view the date of birth of all patients, so I can tell if the are in our jurisdiction.”
or
“As a Workflow Manager, I can always tell the number of people in the call queue and the wait time, so I can make appropriate resourcing decisions.”
Another tip to improve shared knowledge and discussions is to write an acceptance criteria. Acceptance Criteria is a simple, black and white statement that expresses what the customer expects to see and can be used by the team to make sure the requirement is complete, or “done”.
Following on from the examples above, useful acceptance criteria would be;
“A date of birth field against the patient in the format of DD/MM/YYYY.”
and
“On a dashboard I can see a live count of people in the queue and the average wait time”
On smaller projects, you may decide to use index cards and write the requirement on the front and the acceptance criteria on the back. If you are working on a larger project, have many requirements or work with a distributed team, take a look at Bright Green Project to manage all of your Agile Requirements.
Posted by faustochi on March 10, 2010 at 7:10 pm
Hi.
I have read about user stories and how it can be documented using advices like you write here. I think it’s easier when you use it for user interaction and you have real users. Although in my company we build software components and we don’t have real user, we have others systems, interfaces, protocols, and so on. For our team is more difficult uses user stories to describe “enough” (at agile style) all of the thinks related to intangibly component. We are trying to use Conformance section of user stories to describe aspects related to interfaces, performance, availability, readiness. Do you have some experience with this kind of topic?
Posted by Adam Feldman on March 11, 2010 at 12:03 pm
Hi There – What a great question. I’m currently working with a team who have the same issue. The way that they are writing user stories is with the syntax “As a Workflow Process” or “As a batch interface” etc. This is great as it encourages you to think of these “automated” tasks as real users. We find that using the “acceptance criteria” is a great way to capture the additional details as you suggest.