Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first.  This enables them to maximize stakeholder ROI.   Because requirements change frequently you need a streamlined, flexible approach to requirements change management: In short, agilists strive to truly manage change, not to prevent it.   Three versions of this practice are presented: Product backlog (Scrum) Work item list (Disciplined Agile Delivery) Option pool (Lean)

1. Product Backlog: Simplistic

Figure 1 overviews the Scrum approach to managing requirements where your software development team has a stack of prioritized and estimated requirements which need to be addressed (Scrum calls this prioritized stack a "product backlog").  There are several important points to understand:

• New requirements are prioritized by your project stakeholders and added to the stack in the appropriate place.
• Fundamentally a single person needs to be the final authority when it comes to requirement prioritization.  In Scrum this person is called the product owner. 
• Although there is often many project stakeholders – end users, managers, architects, operations staff, and so on – the product owner is responsible for representing them all. 
• The stack/backlog is initially filled as the result of your requirements envisioning efforts at the beginning of the project.
• Each iteration (a "sprint" in Scrum terminology) your team pulls an iteration's worth of work off the top of the stack and commits to implementing it by the end of the iteration.  
• Your project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. 
• Stakeholders are responsible for making decisions and providing information in a timely manner.  On some projects a business analyst, often in the role of product owner, may take on this responsibility.  Whoever is in this role will need to work together with the other stakeholders to ensure everyone is represented fairly, often a difficult task. 
• The priorities of non-requirement work items are either negotiated by the team with stakeholders or are addressed as part of slack time within the schedule.

Figure 1. Scrum requirements management.

2. Work Item List: Disciplined Agile

The approach depicted in Figure 1 is fairly simplistic, a reflection of what I would consider agile construction level thinking. Figure 2 overviews a more disciplined approach which extends the approach described above to managing the work items.  This approach is taken by the Open Unified Process (OpenUP), the Agile Unified Process (AUP) and Disciplined Agile Delivery (DAD) both of which reflect the real-world realities faced by agile delivery teams.  There are a few interesting improvements that you should consider:

Go beyond functional requirements.  We know that we do more than just implement new requirements each iteration, we often do non-requirement related work such as take training, go on vacation, review products of other teams, address defects (I believe that defects are simply another type of requirement) and so on.  The point is that more than just requirements need to be on the stack, we really need work items.  Model a bit ahead.  Because we know that all requirements, let alone work items in general, are not created equal we shouldn't naively assume that we should just wait to pull an iteration's worth of work off the top of the stack at the beginning of the iteration.  What if a work item is very complex, requiring a bit more thinking that what generally occurs in iteration planning sessions?  Disciplined agile teams will adopt the Look-Ahead Modeling practice and look an iteration or two down the work item stack and invest the time to explore complex upcoming work items to reduce their overall project risk. Take a risk-value approach.  Disciplined agile teams recognize that there are common risks faced by development teams, risks which they want to address as soon as possible.  Such risks include the need to come to stakeholder consensus early in the project, a risk which can be addressed through requirements envisioning and perhaps the development of a shared vision or project charter.  Another common risk is the need to prove that your architecture strategy, identified via architecture envisioning, actually works.  The most effective way to do this is to prove your architecture with working code by building an end-to-end skeleton, or steel frame, for your system which addresses the major technological risks faced by your team.  Unified Process and Disciplined Agile Delivery (DAD) teams will look at their work item stack early in the project, typically during the Inception/"iteration 0"/"sprint 0" part of the project to identify requirements which exhibit these technically risky features.  If these requirements aren't at the very top of the stack, and they often are because risk and reward (value) have a tendency to be co-related, then they discuss the issue with their product owner and see if they can motivate that person (who is responsible for prioritization) to move those requirements to the top of the stack too.  If a high-risk requirement is currently near the bottom of the stack then you should question whether that requirement is actually needed because chances are good you'll never actually get around to working on it as higher priority work will always take precedent.

Figure 2. Disciplined agile work management process.

3. Option Pool: Lean

Figure 3 depicts a lean approach, common on Kanban teams, to requirements management.  There are several key differences between the agile approach to requirements/work management and the lean approach: Options. The work items are viewed as potential options to be addressed in the solution, not as required work items.  As an aside, the term "requirement" in IT has always been questionable at best (if something is a requirement then how can some or all of it be dropped from your delivery scope?) but it is a term which I fear we will never be able to abandon. Options are managed as a pool.  Where agile teams manage work items as a prioritized queue, lean teams manage options as a pool from which they work with stakeholders to select the highest value work when they have the capacity to perform the corresponding work.  In effect prioritization is done on a just in time (JIT) with the team's stakeholders.  This can be complex because individual stakeholders will have different priorities, so tradeoffs will need to be made, and because there may be different classes of service being supported by the team.  Of course the risk mitigation issues described by the disciplined agile strategy should also be considerations in which option is selected next. Options are potentially organized into classes of service.  Not all options are created equal.  In the book Kanban, David J. Anderson, describes several potential categories of options (which Anderson refers to as classes of service) which your team may consider.  Many work items fall into the "standard" class where their prioritization is based primarily on their business value to your organization.  Some work items have a fixed delivery date, this is common for requirements resulting from government legislation or contracts signed with your external customers.  You may also have a (hopefully) small number of expedited work items, such as critical fixes for production problems or high-priority customer requirements.  Finally, you may have some low-priority "intangible" work items that you know you'll need to address at some point in the future that you decide to address when the team believes is appropriate (perhaps to streamline other work, to take a rest from more challenging work, ...).  It is important to note that the categories described here are not carved in stone, your team may identify different ones or may not need to categorize at all.  Also, classes of service could be supported in the agile strategies described above as multiple queues. The goal is to limit work in progress (WIP).  When agile teams strive to choose a fixed amount of functionality, just enough that they can implement in a single iteration, lean teams choose to produce a continuous flow of functionality pulling work into their "delivery system" when they have the capacity to do so.  Limiting WIP increases the team's delivery predictability, improves quality (due to shorter feedback cycles), and increases productivity. Old work items are culled.  Lean teams will often strive to identify aging rules where if a work item is in the pool longer than a certain amount of time, it is removed from the pool under the assumption that if it's gone that long without being important enough to be selected from the pool then it likely never will be.  If the work item does prove to be needed it can always be added to the pool at a future date.  Note that the aging rules will vary between teams, perhaps three months for one team although five months for another.  Also, this strategy can be applied to either the product backlog or work item list approaches described earlier.

Figure 3. Lean work management process.

There are several ways that options are added by stakeholders:

• When the team is initially formed, via requirements envisioning session(s).
• In an impromptu manner as stakeholders think of them.
• Via purposeful modeling sessions when the options pool nears being empty.
• As enhancement requests or defect reports identified via usage of the existing production system.

4. Which strategy is right for you?

No one strategy is best in all situations, and you will need to identify choose and then tailor the one that works best for you.  Table 1 compares and contrasts the strategies.

Table 1. Comparing the strategies.

5. Recommended Resources

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.