Does Agile Actually Have Requirements?
Having the words “Agile” and “Requirements” in the same sentence is often seen by some as the highest form of blasphemy. “Agile does not have requirements in its glossary of terms” can often be heard from the depths of the development team. It may well not have the word “requirements” in its vocabulary but there are certainly artifacts that fulfill the role.
The Agile Manifesto
Agile is built around the idea of a fast, customer-focused and embryonic delivery process which is supported by the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile nurtures the requirements and solution so that they evolve into the final delivery. At the center of this nurturing process is the user story, brought into life at the very start, growing and maturing through each iteration and release, gathering more detail for the requirements of the end product throughout the whole process.
Telling a Good Story
Requirements on an Agile Scrum project are gathered in the product backlog and detailed through user stories. Traditionally written on paper or card, a user story is a short, simple description of a feature told from the perspective of the user of the system.
Unlike traditional ways of requirements gathering in which there is a concerted effort at the start of the project to define and tie down what the user needs, the user story and therefore the requirements are time based–growing, evolving and maturing over the course of the releases, iteration and daily planning.
There are several techniques you can use to probe for user stories; I have identified the five techniques that I use on a regular basis, each taking a slightly different approach but each adding to the gathering of information. The techniques on their own will present a good catch of user stories but I would certainly recommend that you combine several techniques. Each can focus on a unique area that may have been missed by using just one approach.
Whichever method(s) are used, always try to follow the INVEST model when pulling the requirements details into the user story. The INVEST model was presented by Bill Wake and is a great template to use when writing a good user story:
- Independent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult.
- Negotiable – Details of the story can be worked out during an Iteration planning meeting. A story with too much detail can limit conversations (at times).
- Valuable – Value to the customer.
- Estimable – There needs to be enough detail for the developers to estimate a user story to allow prioritization and planning of the story.
- Small – A good story should be small in effort, typically no more than 2-3 person weeks of effort (smaller is better)!
- Testable – User stories should be testable with certain acceptance criteria. Saying something like “software should be easy to use” is not helpful.
One Brick Doesn’t Make a Wall
I have worked on archaeological sites and one of the many sayings they have is “one brick doesn’t make a wall.” The same can be
said for Agile requirements gathering–“using one technique doesn’t make a solution”–and I cannot stress enough the importance of using a combination of techniques over the course of the project to uncover the requirements.
Recently I worked with a small software company looking to develop a new product to add to its mobile product set. My first task was to identify the user stories and product requirements. Straightaway we held a workshop with the entire staff, thirteen in all. In the meeting we began by understanding the goal of the product, which had been defined prior to the meeting. With the goal in mind I put a pile of blank cards on the table and started to tease out ideas and break the ice. Soon everyone put forward their thoughts by writing them on the cards. Some thought statements were quite large, and they were broken down further. There were times when we deviated into solving problems but this was quickly brought back on track.
At the end of the workshop we had identified a plethora of user stories and, most of all, everyone became fired up thinking about the requirements. Although much more went on in this meeting, it exemplifies one of the techniques that can be very beneficial when gathering requirements. Further into the project we sent out questionnaires to users and customers to get more focused details and needs. Trawling for user stories is not a single up-front task; it is a continual process allowing us to respond to changes and deliver a more fulfilling experience.
Tools for the Toolbox
There are so many approaches to gathering user stories. Quite often you can spark a very lively debate as to which is best and which
is Agile. The following techniques are certainly recognized and popular and they will do the job. If you have other successful techniques please keep those in you toolbox as well; there are no right or wrong techniques as long as they can identify user stories.
This very common approach to gathering user stories is certainly more effective if the interviews are conducted across a wide selection of users and roles. Try defining a set of questions asked of a selected set of users on a one-to-one basis. The keys to the success of this type of information gathering are the selection of the right interviewees, whether they are users or proxy-users (managers, IT staff, etc.), and asking the right kind of question. Having domain expertise and technical knowledge will certainly help in pulling the stories together.
Asking the right kind of question can be a science in its own right and will almost certainly impact the value of the user stories gathered. Asking open-ended and context-free questions is the best way to entice the actual needs from the interviewees.
The open-ended questions usually ask “how” or “what.” The person being interviewed is then free to interpret an open-ended question and provide the details in any way he or she likes. For example, “Tell me how you would like to search for a book” will get a far better response than “Will you search for a book by title?”
The context-free question will also give you a far better insight into the requirements by not putting boundaries on what you are trying to obtain from the interviewee and therefore does not include an implied answer or preference. For example instead of “How fast do the book searches need to be?” ask “What kind of performance is required when searching?” Context-free questions are great for teasing out requirement that may otherwise have been missed in the early part of the project. Later on in the process you may need to get into more details, and then the use of context-specific question may provide information you are seeking.
At a government office recently I set up a workshop where we used prototyping to stimulate user requirements; we had already done a story-writing workshop. The session quickly identified stories that had been missed in previous sessions as the users could now relate to the future product. Prototyping, an excellent way to present ideas and nurture communication, can highlight areas that had been overlooked and provide valuable incite into the user’s approach to work. You might be surprised how quickly users realize that what they have asked for is not necessarily what they want. The way you present the prototype is very flexible and it can be done by wire framing, Powerpoint or even sticky notes–as long as you can present the ideas and see the work flow, then anything is acceptable.
It is important to note: At the end of any prototyping session you must destroy the prototype. It is not a permanent project deliverable.
Questionnaires are highly effective in gathering more information and prioritizing the user stories that are already in hand and have a large user population.
The questionnaire should not be the primary means of getting information from users. It neither allows you to follow the user down a path nor lends itself to follow-up questions. The ideal situation for using the questionnaire is when you require further detail about a specific area or you want information in order to prioritize stories.
The opportunity to observe how the users use an application can be rare, but the information obtained during a meeting can certainly improve their productivity and experience. This makes it an invaluable tool in the development of the user stories. Whenever possible I book a session with a user not only to understand how he operates but also to improve my domain knowledge. That provides me with far greater insight when pulling together the user stories.
Story-writing workshops are probably by far the best technique for identifying and formulating user stories. The technique, similar to brainstorming, brings together the users, Product Owner, Scrum Team, etc., who then discuss and identify as many user stories as possible. This workshop does not prioritize and estimate the user stories but solely identifies requirements. The workshop must be managed well; it can easily slip into design- and problem-solving side tracks. Remember that the purpose of the workshop to identify as many user stories as possible at a very high level.
This technique is very effective during release planning.
It is important to remember that techniques will not make good user stories and neither will they identify all requirements. There is a lot of skill required to tease out information from the user, and this tends to improve with experience and domain knowledge. Having said that it is always important to have a good set of tools in your bag.
While trawling for user stories you will inevitably come across non-functional requirements. Common areas of non-functional requirements are:
Many of the non-functional requirements can be identified as constraints on the system and should be written on a card and annotated with “Constraint”. Constraint cards are not estimated nor scheduled but they do act as a reminder to developers and are a measure in acceptance testing. Non-functional requirements that fall outside of a constraint can be held and communicated in whatever form is suited or traditionally used, a data dictionary is a good example where, for example, a customer number is mandatory, it must be numeric and always 10 characters long.
- Gathering requirement details on an Agile project is primarily done through user stories using user interviewing, user observation, questionnaire and story writing workshop techniquies.
- To get an informative answer from a user try to keep the question open-ended and context-free.
- Agile requirement details in the form of user stories are embryonic, growing and evoling as you move through the life of the project.
- For best results, use a combination of requirements gathering techniques, remember “one brick doesn’t make a wall”.
Please be sure to check out the other items in Bright Hub’s collection of Agile project management guides and discussions.