Before you start running around your office shouting buzzwords about Agile requirements gathering, you should take the opportunity to educate yourself about Agile software development in general.
What Is Agile Software Development
Agile software development is more than buzzwords practices like sprints, test-driven development (TDD), stand-ups, planning sessions, and sprints.
Agile software development isn’t a specific thing per se, but rather a group of iterative and incremental software development methods based on the values and principles expressed in the 10 Commandments of software development God gave to Moses at Mount Sinai Manifesto for Agile Software Development and the 12 Principles behind it.
If you dive deep enough in to Agile indoctrination literature, it starts to sound a little culty, but hey, what doesn’t these days. Half of what Agile proposes only works on paper, like this little beauty referenced below:
One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.
So sure, if you want to ignore the realities of working inside a company and assume you have a can opener, knock yourself out. Having said that, there is lots of value for product managers within the Agile framework, especially when it comes to understanding the product requirements gathering process and adapting to change.
Agile Requirements Gathering
One of the things that software developers and product managers love to argue about is semantics, which while fun over a bottle of whisky, tends to get in the way when at work.
While Agile may not have the explicit term “Requirement” in its glossary of terms, apply some abductive reasoning to the listed terms like user story, customer development, sprint planning and backlog grooming and you pretty much pass the “Duck Test” where requirements gathering is concerned.
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
So whether you want to call this activity Agile requirements gathering or doing “customer development” in order write “user stories” or “user scenarios” for use in “acceptance testing”, you are doing the same thing, so get off your semantic high horse, stop splitting hairs and build something already. The most important goal in this entire process is to create a shared understanding among teams.
But wait, there is more confusion, if you Google “Agile requirements gathering” what you will come across is a number of articles that conflate terms from across the product development lifecycle. Some articles include topics about adding details to user stories and prioritization while others list out requirement gathering techniques, many of which we covered in “How Do Product Managers Validate A Product Hypothesis“?
My personal perspective is that this confusion arises from the ongoing, iterative nature of requirements gathering within Agile methodologies. The reality is that there is no specific Agile requirements gathering document or process, but rather the term refers to the iterative nature of the methodologies.
As discussed, Agile requirements gathering allow flexibility and transparency compared to purely sequential approaches; these approaches emphasize upfront gathering (like way up front….months and months upfront), review and approval of detailed requirements.
In these sequential models, approved requirements are unlikely to change as change requests are often costly and disruptive. If you have never worked on a truly waterfall environment, you may not have a proper reference point for understanding this distinction, so Agile requirements gathering is not a specified format, but rather a number of methodologies that get used as needed.
While yes it is true, detailed requirements are not documented all at once at the beginning of a project, high-level requirements are, as they are needed for establishing technical requirements.
Agile requirements gathering is done on an on-going basis, bridging the gap between these high level requirements and what you need to feed the development team so they build the product expected by the product roadmap and corporate strategy.
The whole process of agile requirements gathering is to determine the contents of the “living” product requirements document, which includes:
- Which user stories should be prioritized for development serve as a starting point for both product requirement and technical requirements.
- Which use cases should be written, with an emphasis on acceptance criteria and scenarios.
The Role of User Stories in Agile Requirements Gathering
- Capture a description of a software feature from a user’s perspective.
- Describe the type of user, what they want and why.
- Create a simplified outline of a requirement.
- Outline how a project delivers value back to the end user.
- Facilitate the creation of use cases.
- Enable developers to estimate and plan work, creating the code that satisfies the requirements of the user story
In order to create the most useful user stories, each story must be:
- Independent: A user story must be independent from other stories.
- Negotiable: Stories are not waterfall specifications and offer opportunities for negotiation and change.
- Valuable: Every story adds value (benefits) for users and stakeholders.
- Estimable: You need to be able to calculate the time and development resources for each story.
- Small: Stories must be small enough to estimate accurately and implement simply.
- Testable: A user story needs to outline acceptance criteria.
How To Improve The Agile Requirements Gathering Process
- The iterative nature of requirements gathering associated with Lean methodologies.
- Using a short and concise product requirements document that is updated in real time, rather than an unchanging tome.
In order to make the requirements gathering process smoother in an Agile environment, consider implementing the following protocols:
- Concise requirements: Smaller concise requirements, lead to smaller feature sets and user stories that generate more accurate estimates, leading to a better prioritization of resources and fewer dependancies.
- Robust user stories: Include enough information for development decisions. Don’t take the name Agile to mean you leave details out of complex or mission-critical projects; the higher priority the requirement, the more detailed the item should be.
- Prioritize Requirements Based on Resources: Developers estimate the time and money necessary to implement the feature or functionality of a requirement. Once done, these are prioritized by the product owner, product manager and lead developer against time and budgets restraints; the reality is that not all requirements make it into a given sprint.
- Keep relevant stakeholders involved: Don’t let software development go on in isolation from other stakeholders, like UX designers and product owners. Keeping all stakeholders updated regularly means that any new requirements or deviation from requirements, gets noticed quickly with each iteration.
- Focus on functional requirements: Working backwards by focusing on the function you need a feature to perform. This allows the identification of:
- What act needs to be performed.
- Cross-requirement dependencies.
- Potential technical limitations.
- Start with a prototype: Starting with a prototype allows for:
- The testing of ideas
- Discussion with stakeholders over requirements.
- Risk mitigation via testing and redesign
- Design refinement.
Handling Non-Functional Requirements In Agile
There are numerous non-functional requirements that must be met by any product. Typically, these are considered constraints and relate to the technology requirements of the underlying system:
- Availability
- Performance
- Maintenance
- Security
These requirements must be factored in to the overall architecture of the system and are used in acceptance testing.
