Leading Techniques for Gathering Project Requirements and User Stories
In the traditional (aka Waterfall) project management approach, high-level requirements are gathered at the initial stage. The objective is to develop a well-defined scope before kickoffs a project. Traditional requirements are criteria to which the software or business must adhere.
Here are the five requirement attributes:
There are eight techniques to gather requirements:
1. Interviews (Formal or informal one-on-one interviews)
The most common technique for gathering requirements is to sit down with the clients and ask them what they need. Subject matter experts should be used here as they are more able to articulate what the product should consist of and why this is important. The project manager or a business analyst may conduct such interviews.
2. Focus groups (Pre-qualified stakeholders and subject matter experts)
These are carried out by a member of the project team meeting with a group of stakeholders to determine their requirements, needs and expectations for the project and its outcome.
3. Facilitated workshop (Cross -functional stakeholders)
In a facilitated session, you bring a larger group together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately.
4. Group creativity techniques
Generating a creative environment where people can openly discuss their ideas is a powerful and creative way to ensure the requirements are fully captured. Techniques can include; brainstorming, nominal group technique using votes and priorities, diagramming techniques such as mind mapping, and where a participant’s real unbiased opinion is needed, the Delphi technique.
5. Group decision making techniques (unanimity, majority, plurality and dictatorship)
6. Questionnaires and surveys
Using a standard questionnaire or survey allows requirements to be gathered quickly among large groups of people and because of the standard format, analysis is also quicker.
Put simply, an observer watches as a worker performance their job and note how the worker performance this last capturing less obvious requirements that would be missed by other methods.
A prototype’s use and style will depend upon the end product of the project and any methodologies being used for its creation. One or more part-functioning prototypes can be a powerful visualization aid when attempting to understand requirements.
In an agile iterative project, requirements take on a form of user stories. A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
It is not a highly documented requirement, but rather a reminder to collaborate and communicate with the team about the topic of the user story.
The basic components of a User Story (Three C's):
Card (or a Post-It note) - A physical token giving tangible and durable form to what would otherwise only be an abstraction.
Conversation - A conversation taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, and testers. This conversation is largely verbal but most often supplemented by documentation.
Confirmation- The objectives the conversation revolved around have been reached.
A well-written user story follows the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) model:
One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
A user story is negotiable. The "Card" of the story is just a short description of the story which do not include details. The details are worked out during the "Conversation" phase.
Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. All stories should be connected to clear business goals.
The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality.
The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog. This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.
Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.
“The goal of using stories isn’t to write better stories. The goal of product development isn’t to make products.” ~ Jeff Patton