Project Management Institute

High speed, high quality, high impact

the power of agile requirements


The term “agile,” and its association with software development and process improvement, has been around for a lot longer than you might think. In fact, back in 1986, the Harvard Business Review published an article authored by Hirotaka Takeuchi and Ikujiro Nonaka titled “The New Product Development Game” (Takeuchi & Nonaka, 1986). The article made several references to what would eventually be the backbone upon which the Agile Manifesto grew. The article cited that anticipation and even encouragement of changing requirements, self-organizing teams, integrated development phases, all-stakeholder collaboration and decentralizing control were key success factors in developing personal computers, the inkjet printer, motorcycles, and the automobile!

In 2001, at a ski resort in Snowbird, Utah, USA, some of the greatest pioneers in software development history gathered to put into motion a framework that drove the very themes about which Takeuchi and Nonaka wrote in 1986. The Agile Manifesto (Beck, 2001) is now well known throughout the world and is practiced using a variety of software development methods, including:

  • Agile Modeling,
  • Agile Unified Process,
  • Dynamic Systems Development Methods,
  • Essential Unified Process,
  • Extreme Programming,
  • Feature Driven Development,
  • Open Unified Process,
  • Velocity Tracking and
  • Scrum

Twelve principles form the framework of the Agile Manifesto (Exhibit 1). These principles will serve to guide the development of the rest of this paper.

For the purposes of this paper, it is important to distinguish between frameworks and methods. Merriam-Webster provides the following definitions for the word “framework:”

a: a basic conceptional structure (as of ideas) <the framework of the United States Constitution>
b: a skeletal, openwork, or structural frame…[(Framework. Merriam-Webster Online Dictionary)].

“Method” is defined by Merriam-Webster as follows:

1 : a procedure or process for attaining an object: as a (1) : a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2) : a systematic plan followed in presenting material for instruction b (1) : a way, technique, or process of or for doing something (2) : a body of skills or techniques 2 : a discipline that deals with the principle of techniques of scientific inquiry 3 a : orderly arrangement, development, or classification : plan b : the habitual practice of orderliness and regularity…[(Method. Merriam-Webster Online Dictionary)]

Agile Manifesto Principles (Beck, 2001)

Exhibit 1: Agile Manifesto Principles (Beck, 2001)

The implementation of these “practices” can be best summarized as “practicing a method that is governed by the principles of a framework,” as demonstrated in Exhibit 2.

Agile Manifesto Implementation

Exhibit 2: Agile Manifesto Implementation

Regardless of what method an organization selects, the heart of any good solution—whether for manufactured goods or services provided to customers (internally or externally to an organization)—lies in the project's requirements. Requirements are often the driver behind successful implementations. It must be noted, however, that requirements are highly dependent on a large variety of complex moving parts. Structure, discipline, and trial and error must be fundamental practices of any method in order to navigate said complexities. It is important to note that adequate time must be allowed to put into practice the concepts presented in this paper. Incorporating these concepts is deserving of the highest executive management support and requires a willingness to make fundamental changes to traditional methods with which you may have grown comfortable.

Let's start with what Dean Leffingwell refers to as the “Iron Triangle” (Leffingwell, 2001, p. 6). Traditional software development methods foster an approach that would suggest that requirements determined at the front end of a project serve as the basis for estimating schedules and budget. This is typically referred to as a “plan-driven” type of approach. Nine times out of ten, these types of projects are bound by budget and schedule and, as such, “locked” into the pressures of delivery—hence, the term “iron triangle.” In the world of agile the only two fixed “parameters” are schedule and resources and, if practiced with discipline, quality also becomes fixed. Don't forget the first two principles of the Agile Manifesto: “1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software,” and “2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” Leffingwell goes on to demonstrate how agile increases return on investment through the valued delivery of goods and services.

It is important to note that with many organizations the implementation of scrum is often so exciting that core principles of development—such as the “The Big Picture Planning” component—are overlooked. More often than not, scrum is something that is thought of, ironically, after the fact. As such, let's start at the beginning. Fundamentally, there are three levels of requirements that must be considered in an agile environment: the portfolio layer, the program layer, and the team layer (Exhibit 3).

The Three Levels of Agile Requirements

Exhibit 3: The Three Levels of Agile Requirements

The Portfolio Layer

At the portfolio level there are essentially two types of requirements that are addressed. These are the highest level of requirement, and for the sake of comparison can be easily likened to the International Institute of Business Analysis's Business Analysis Body of Knowledge (BABOK® Guide) definition of Business Requirements. According to the BABOK® Guide, “Business Requirements are high-level needs, goals or objectives of an enterprise in its entirety” (BABOK Guide®, 2009) In the agile world these “business requirements” are in fact divided into two separate categories: investment themes and epics. The portfolio management team is ultimately responsible for providing direction and support to its corresponding lines of business and, as such, investment themes come in four distinct “flavors:”

  • In vestment in existing products/goods and services (maintenance, repair, or updates)
  • Investment in new products/goods and services (increase profitability, increase market share, maintain technological “pace”)
  • Investment in future products/goods and services (research and development-type efforts in anticipation of future needs)
  • Decommissioning of products/goods and services (removal of wasteful goods and services that are no longer required or are proving to be more expensive to maintain, service, or update)

Themes are typically addressed on an annual basis or twice a year (typically at budget time). The project and program management offices, respectively, generally support the realization of such themes. Realization of investment themes and their value are in turn supported by the development of epics. It should, however, be noted that not all epics need be supported by investment themes. This second level of abstraction is considered to be a hilevel of abstraction and, as such, epics need only be captured in bullet form. Epics should not be more than two sentences in length and they must support vision, not specificity. Leffingwell states that epics must be captured in high enough detail to initiate further conversation for the development of features and, finally, stories (Leffingwell, 2001, p. 87). To do so allows for interpretation of requirements in ways that are easiest to implement. Bear in minthat at this point we are only working on portfolio-level requirements, the risk is relatively low, and any error in judgment is easily corrected at minimal costs given the decreased overhead of the number of non-specific requirements. Epics are identified, prioritized, estimated, and resiide in the portfolio backlog, where they are monitored and maintained by the Portfolio Management Group.

The Program Layer

Generally speaking, the product manager is the title best suited to describe the individual or groups of individuals who have oversight of the program layer, although program managers and business analysts are appropriate for this role as well. It is the intention of this layer to release potentially shippable increments of a given solution, although it is not a mandate. At this layer, careful consideration of the implementation of said features may be impaired by a variety of variables including, but not limited to, such things as:

  • Disruption of existing day-to-day operations
  • Existing service level agreements or licensing agreements
  • Change management challenges, including training
  • Financial constraints that may have evolved out of technical defects, including performance compliance and reliability

The program backlog is the primary source for derivation of all activity; it serves as a focal point for the maintenance and delivery of vision and features of a proposed solution or solutions. It is important to note that the vision described here is specifically the vision defined for the solution that is to be developed. The vision is intended to answer questions such as: What is this solution attempting to resolve? What features and benefits must it support? Who will be the target audience for the solution? What non-functional requirements must be considered? What technological constraints must be addressed and subsequently supported? Ultimately, the primary content of the vision is features. These features must be prioritized and bring value to respective stakeholders. Teams within the program layer determine what is called a product roadmap. This roadmap is an agreed-upon path for which release planning will take place; it includes committed release-by dates, themes, objectives, and a prioritized feature set. It should be noted that as teams begin to decompose features into stories, development facts, business needs, and priorities may change. As such, the Agile Manifesto encourages teams to remain agile and evaluate each circumstance as it arises.

The Team Layer

The team layer is the group at the front line, “in the trenches,” whose primary responsibility is to define, develop, test, and deliver working software. It is here where features are decomposed into stories, and stories are developed into software. Teams consist of seven to nine members best suited to designing and developing software. Team members consist of a product manager, developers, and testers. These teams are supported by all “cast” members, including data base architects, business architects, quality assurance personnel, subject matter experts, and so forth. The Scrum Master or Agile Master has a specific role at the team layer; his or her primary responsibility is to ensure the team is enabled to be successful. This individual is responsible for facilitating the team toward delivery of a functional product, enforcing the rules of agile, and ultimately removing any obstacles that may prevent the team from achieving its defined goals and objectives.

Teams have a responsibility for delivering either features or components, and this largely depends on the nature of the organization and its structure. The third and final layer of requirements is often captured, documented, prioritized, and estimated much the same way previous backlogs have been described. The team backlog is also referred to as the sprint backlog using scrum methods. This repository's content is largely that of user stories but can also contain other work items. User stories have often been referred to as a replacement for traditional software requirements. User stories are broken down into tasks that are further decomposed by the team with the explicit intent of ensuring a detailed approach to estimating and allocating resources for the delivery of a feature and its supporting user story(s). Although the user story supports the tasks, it is important to note that user stories also support the development and execution of acceptance tests. There needs to be at least one acceptance test for each story, and a story may be supported by multiple acceptance tests. Acceptance tests may or may not be supported by a single (or multiple) acceptance test.

A summary of all three levels of requirements is captured in Exhibit 4.

Summary of Levels of Agile Requirements

Exhibit 4: Summary of Levels of Agile Requirements

Layers of Requirements in an Agile World

Exhibit 5: Layers of Requirements in an Agile World


Now that the various levels of requirements have been laid out, the next step is to understand the techniques through which requirements in an agile world can be brought to life (Exhibit 5).

An understanding of high-level requirements is critical at iteration 0 in the agile requirements life cycle. A clear understanding of fundamental business questions, critical business issues, and respective areas for improvement is essential, and reduction of risks by ensuring maximum stakeholder participation is vital. It is here that high-level use case models and domain models are employed to ensure the path is paved for subsequent decomposition activities. An example of a high-level use case, and its level of detail, is shown in Exhibit 6.

Detailed Example of High-Level Use Case

Exhibit 6: Detailed Example of High-Level Use Case

Exhibit 7 represents it as a UML Use-Case Diagram:

Example of UML Use-Case Diagram

Exhibit 7: Example of UML Use-Case Diagram

Alternatively, a domain model for an expense management system is shown in Exhibit 8.

Example of Domain Model

Exhibit 8: Example of Domain Model

It is important to keep these models at a high level of abstraction to ensure any potential waste is not of significant size or value. The more detail, the greater the opportunity for missing errors or erroneous data, as extra detail clouds clarity of communication. All details cannot possibly be covered in the initial stages of identification and, therefore, it is crucial to allow time for change, growth, and learning.

Architectural envision is a critical component when considering the agile-driven modeling approach, allowing for reduction in technical risks, increased speed for development, team development, and communication. Drawing out the potential architecture for a system provides developers with a real sense of the initial technological risks they are likely going to have to overcome for the system in question. Creating the business architecture will also allow for consideration of fundamental business rules and the processes that will most likely play a significant role in the logic that will guide many decision-making processes the software will eventually support.

Model storming is a great way to facilitate overcoming challenges that the group is likely to face along the path to development, and it encourages team members to analyze requirements quickly and efficiently. Best practices recommend white boarding/sketching models out with all team members actively participating in the development of whatever model is being used or multiple models demonstrating various levels of abstraction. The most commonly used models include activity diagrams, state diagrams, use case models, domain models, decision trees or tables, and entity relationship diagrams. Model storming essentially is a facet for overcoming ever-changing requirements, and is meant to be an “on the fly” means of developing clarity around those requirements that are added or become higher on the priority list in the sprint backlog.

How can changing the requirements be managed in the context of an environment that is constantly changing and even encourages change? First, we must we must accept the fact that requirements will change as we learn from evolving business needs and requirements. Treat requirements as a “prioritized stack” found in the product backlog. Prioritized items are also estimated items. Remember that stakeholders, in particular the product manager and in some cases the business analyst assigned to the project, are responsible for prioritizing said stack, and developers do the estimating. At the beginning of each iteration in a planning session, the team will take from the stack a list of prioritized items it feels it can accomplish given the timeframe set forth in the sprint; this is likely accomplished through a series of conversations, negotiations, and modeling.

It must be noted that although models should be the driving force and backbone of the initiatives, a glossary of terms is equally important. In fact, one could easily argue that without a glossary of terms the development of models will prove more challenging than the team initially thought. A glossary of terms sets the standard for language to be used, and if done properly erases all that can be easily misconstrued, or taken for granted. A glossary of terms is not simply a placeholder for spelling out acronyms. A glossary of terms if constructed according to industry best practices should describe the term, its acronym, and any aliases, and use the acronym in a context that one might expect to see it used.


When planning on adopting agile practices within an organization keep in mind the following:

  1. It doesn't happen overnight.
  2. Strong executive management support is required.
  3. Understanding levels of requirements will simplify your approach.
  4. The Agile Manifesto is the best guide to consider when adopting an agile approach.
  5. Understanding of team roles and their capabilities will decentralize the decision-making process and consequently the learning process.
  6. Requirements, priorities, and estimates will change.
  7. Model-driven development has been proven to reduce waste by detecting defects before costs rise exponentially to correct them.
  8. Change is managed through the various backlogs and changing priorities of market demands, learning, governance, and technological advance.
  9. Smaller is easier to estimate, manage, and prioritize.
  10. Finally, the overarching goal is to be structured, disciplined, and agile all at the same time. It requires practice and above all learning and the latitude to experience challenges and resolve them collectively and collaboratively.

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler M. et al. (2001). Manifesto for Agile Software Development Retrieved from

Framework. In Merriam-Webster Online Dictionary. Retrieved from

International Institute of Business Analysis. (2009). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide® (2nd ed.). Toronto, Ontario, Canada: International Institute of Business Analysis.

Leffingwell, D. (2011). Agile Software Requirements, Lean Requirements Practices for Teams, Programs and the Enterprise. Boston, MA: Pearson Education Inc.

Method. In Merriam-Webster Online Dictionary. Retrieved from

Takeuchi, H., & Nonaka, I. (1986). The New Product Development Game. Harvard Business Review, reprint 86116. All pages.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2011, Glenn R. Brûlé
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas/Fort Worth, Texas, USA



Related Content