Agile development approaches are currently used in most software organizations at least some of the time. With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work.
My co-author, Joy Beatty, and I do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. However, we contend that a developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.
Agile and traditional projects do handle requirements differently in various respects, particularly with regard to the timing and depth of requirements activities and the extent of written requirements documentation. Nonetheless, most established techniques for requirements development and management are useful on agile projects when thoughtfully applied, as described in our book Software Requirements, 3rd Edition. This is why we prefer the term “requirements for agile projects” over “agile requirements.”
Traditional approaches, such as waterfall development, attempt to minimize project risk by doing extensive specification and planning prior to initiating construction of the software. In this way the project managers and BAs make sure that all stakeholders understand exactly what will be delivered before it gets built. This can work well if the requirements are well understood at the outset and are likely to remain relatively stable during the project.
Agile approaches are designed to accommodate and adapt to the inevitable change that takes place on many projects. They also work well for projects with highly uncertain or volatile requirements. However, agile projects require fundamentally the same types of requirements activities as traditional development projects. Someone still needs to identify user classes and other stakeholders, elicit requirements from appropriate user representatives, analyze and document requirements of various kinds at appropriate levels of detail, and validate that the requirements will achieve the project’s business objectives. However, detailed requirements are not documented all at once at the beginning of an agile project. Instead, high-level requirements, typically in the form of user stories, are elicited to populate a product backlog early in a project for planning and prioritization.
There Is a Difference
The major differences between how requirements activities are handled on agile and traditional projects fall into the following categories.
Roles and Responsibilities
Agile projects often do not assign a dedicated business analyst to perform elicitation, analysis, specification, and reviews. Developing requirements-related information is a collaborative process among people performing the role of analyst, regardless of their actual job titles, and suitable user representatives and other stakeholders. The analyst role commonly is performed by a combination of a product owner, developers, and key business stakeholders.
On an agile project, a product owner typically is responsible for the product backlog and for getting the user stories ready to be implemented. The developers are responsible for ensuring the user stories contain enough information before accepting them for development. Sometimes the product owner role is filled by someone who was formerly known as a business analyst, as long as that individual knows the business well and can represent the various user communities effectively. Other projects do have a dedicated BA who works closely with the product owner to ensure user stories are sufficiently elaborated and prioritized for development.
Timing of Requirements Activities
In any software development approach, starting with a broad exploration of requirements at a high level of abstraction allows you to do some initial prioritization, estimation, and sequencing. Traditional approaches emphasize creating a fairly complete and detailed requirements specification early in the project. In contrast, agile teams plan to generate the requirements details just prior to implementing a specific set of functionality. This reduces the risk of the information being obsolete when developers and testers need to act on it, and it helps the team to refine priorities. However, a just-in-time approach makes it harder to recognize requirement dependencies and architectural implications that should be addressed from the very beginning. To mitigate the risk of a flawed architecture, agile teams often do look at the broad scope in early iterations and consider what major architectural decisions might be necessary.
As shown in Figure 1, agile user stories are allocated to specific iterations for implementation, and the details for each story are further clarified just in time for, or during, that iteration. Functional requirements might continue to be developed in small portions throughout the entire project, even up until shortly before the product is released. As with architecture, though, it’s important to explore nonfunctional requirements early on so the system can be designed to achieve critical performance, usability, availability, and other quality goals. Addressing these factors late in the project can require extensive and expensive rework. Just as with traditional approaches, agile methods are about reducing the risk sufficiently to move forward. The big difference is that agile projects anticipate doing a certain amount of refactoring and rework, so teams are willing to accept more requirements uncertainty early on.
Figure 1. Standard requirements activities occur within each agile iteration.
At the top level, user stories are comparable to the use cases often used on traditional projects. Again, the distinction is in how thoroughly you detail them and whether you record what you learned when you did. User stories often correspond to individual flows within a use case. The BA on a traditional project might work from use cases to develop a richer set of functional requirements. On an agile project, in contrast, the team commonly fleshes out the specifics of a user story by writing acceptance tests that will indicate whether the story has been properly implemented.
I have advocated developing tests in conjunction with requirements for nearly 25 years — long before the Agile Manifesto was born! But in reality, functional requirements and their corresponding granular tests are both ways to represent the same information, one describing what to build and the other specifying how to tell whether you’ve correctly built the right thing. A big advantage of thinking in terms of tests is that they are more likely to reveal exceptions that are often overlooked when specifying requirements. However, the disadvantage of using only one or the other is that it leaves you with but a single representation of the requirements knowledge. If you have only one view of the requirements, you must trust it to be correct.
We have found that writing both requirements and tests provides a powerful combination, particularly if a different person than the one who wrote the requirements writes the tests from the same source of information. Comparing those two alternative views is a great way to find gaps, ambiguities, and differences of interpretation. On agile projects this is not usually practical based on team roles, because product owners typically write both the user stories and the acceptance criteria.
The different forms used to represent requirements lead to an interesting but not terribly meaningful difference in the terminology used on traditional and agile projects. Most agile projects refer to user stories and acceptance criteria, whereas use cases and functional requirements are more commonly employed on traditional projects. But it’s really the same knowledge! It doesn’t matter much what you call it or exactly how you represent it, just so long as you produce and communicate that knowledge in a way that lets developers and testers do their jobs effectively and efficiently.
People sometimes think agile project teams aren’t supposed to write requirements. That is not accurate. Instead, agile methods embrace the principle of lightweight documentation. The close collaboration of customers with developers on agile projects generally means that requirements can be documented in less detail than on traditional projects. Instead, BAs or other people responsible for requirements will develop the necessary precision through conversations and documentation when it is needed.
Any documentation beyond what the development and test teams need (or that is required to satisfy regulations or standards) potentially represents wasted effort unless there’s a definite need for it down the road. Certain user stories might have little detail provided, with only the riskiest or highest-impact functionality being elaborated in more detail, typically in the form of acceptance criteria and appropriate visual analysis models.
I believe the cost of recording information is small compared to the cost of acquiring that information. There is considerable merit in creating a persistent group memory in written form because human memories are incomplete, are inconsistent, and decay with time. People come and go on project teams, and of course the product continues to exist long after the development project is done. Each project needs to select a sensible balance point of just-enough documentation to manage those risks without spending unnecessary time recording information that won’t be used.
When to Prioritize
Prioritization of the backlog is an ongoing agile project activity to select which work items go into upcoming iterations and which items are discarded from the backlog. The priorities assigned to backlog items don’t have to remain constant forever, just for the period each is under development. The teams are always asking themselves: “What is the most important thing to work on next?”
In contrast, most traditional projects try to prioritize requirements early and rarely look back. But really, all projects — not just agile projects — ought to dynamically manage the priorities of the work remaining in their backlog as it ebbs and flows.
Is There Really a Difference?
We recently saw a list of “Principles of Business Analysis” from the IIBA® Agile Extension to the BABOK® Guide that itemizes numerous practices in several categories. We are hard-pressed to see anything there that would not potentially be useful on any software project. Shouldn’t every team apply techniques to see the whole, think as a customer, stimulate collaboration, and avoid waste?
All projects should define what business value means, ensure that both project activities and business process steps add value, and use practical prioritization methods. Techniques like personas, backlog management, relative estimation, and retrospectives are valuable practices that would benefit nearly any project. So what makes these BA principles and practices specific to agile projects?
Now, you could argue that traditional projects often do not conform to these principles or perhaps effectively apply any set of thoughtfully selected BA practices. Probably true. Probably just as true on agile projects that might not have organic BA expertise. But the basic point is that, the same requirements values, principles, and practices are equally applicable to any software project when thoughtfully adapted, scaled, and timed so as to enable the project to achieve its objectives. That’s why we just don’t get the idea that “agile requirements” are somehow different and special.
If you’re interested in requirements and business analysis, Process Impact provides numerous useful publications and other resources.