Responding to Changing Requirements in Agile Iterative Cycles

The 4 Agile Values and 12 Principles guide us to:?

• Respond to Change over following a plan (that is, while there is value in following a plan, we value Responding to Change, more). Agile value #4.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (Agile principle #2).

However, we don't arbitrarily allow ourselves to get blown over by every change requested–like the wind whenever it blows. We use the "agile process to harness change" in an organized, responsive manner.

Agile was founded partly on the fact that plans change. We must be responsive to those changes to "satisfy the customer through early and continuous delivery of valuable software." Agile principle #1.?

However, it is also founded on the premise that "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." Agile principle #8. A constant pace is not synonymous with constant or continuous changes without a plan to manage them. Benjamin Franklin said, "if you fail to plan, you're planning to fail."?

Iterative agile frameworks support teams in responding to changing requirements while maintaining a constant pace–indefinitely. It's like harnessing the power of the wind to your and the customer's advantage–instead of it blowing you over.?

Requirements and Change Management

This is still a thing even in agile methods! Agile has a way of being able to start with minimal or even vague requirements, and it handles concrete requirements quite well, but don't we all? The more we know about what a customer needs, the better we can meet their needs and expectations in a timely, quality, and cost-efficient manner. Agile methods and frameworks don't forgo these best practices. They optimize them.

Early feedback in the iterative cycles helps us meet expectations or helps the customer realize they need something different sooner than later, regardless of whether we start with vague, concrete, or changing requirements. We all win early with a solid management plan ready and equipped to change when we must.

The requirement scenario subsections in this document offer guidance; however, changes within each adhere to the same cadence and feedback loop built into agile iterative frameworks.?

A key to aligning business stakeholders and agile delivery teams toward achieving the same goals (even when they change) is embracing another agile value. "Customer Collaboration over contract negotiation." (That is, while there is value in contract negotiation, we value Customer Collaboration more). Agile value #3.

In Scrum and other iterative frameworks, Business Stakeholders are represented by a Product Owner who sits on the Agile Team. The Product Owner is the voice of the customer when facing the agile team. However, the business stakeholders participate and voice themselves directly and orderly during the SDLC. Not just at the end when they're ready to do a full-blown UAT on the sum of all increments produced within iterative cycles.

Direct communication with the Product Owner and Scrum Master (or equivalent roles on the Agile Team as hybrid processes may use different counterpart titles) occurs as needed during the project cycle. However, communication with the agile team (including developers and testers) happens once every iteration (1 or 2-week cycles).

Before the iterative development cycle begins, communication and interaction between the business stakeholders and the product owner will be more frequent to establish the business case and objectives before planning execution. This may seem like contract negotiation, but remember that we actually do value this concept. We just value collaboration more, supported by the Product Backlog, which is an emergent, ordered list of what is needed to deliver or improve a product. It also serves as the single source of work undertaken by the Agile Delivery Team. (No one or thing outside of the Product Owner and the Product Backlog can direct the agile delivery team on what to do and when).

The Product Owner will build a roadmap and an ordered product backlog representing the stakeholder needs as product backlog items (PBIs) in the form of agile Features and User Stories. Because the Product Backlog is a living document, stakeholders can request changes to the Product Backlog through the Product Owner–at any time. Doing so, however, may impact the roadmap and overall plan concerning time, cost, technology, etc., so it is essential to assess the impact of changes and gain agreement before they are implemented.?

The Product Owner invites and involves business stakeholders at specific times within the iteration cycle to observe and provide feedback and makes all work transparent so that stakeholders are aware of the daily state of the project. The Product Owner may involve the agile team's Scrum Master to facilitate and assist in providing information.

Once items on the product backlog have been committed to an iterative development cycle (a subset of the Product Backlog contained in an active Iteration Backlog), no changes to the work in that iteration can be requested or accommodated. However, suppose a change is so significant that stakeholders cancel the project. In this case, the project can be changed but is not likely to continue where the other left off in the last iteration, as it will require a new plan, roadmap, backlog, etc.?

The iteration is a short cycle that produces a verified working increment of the product as defined within the committed PBIs and iteration goal. Changes to the increment or redirection based on stakeholder feedback are collected at the end of every iteration and implemented in subsequent iterations based on the order added to the Product Backlog by the Product Owner.

Note: Other customer/business project artifacts help guide and drive the Product Owner toward forming the Product Backlog. Such as an official Business Requirements Document (BRD) or a Statement of Work (SoW) may contain the customer's business requirements or require definition and approval before development can begin. These are good artifacts and practices in any delivery method and framework, including agile. However, as we established earlier, they must be represented in an agile Product Backlog to be delivered by an agile team. This warrants "artifact traceability." Keep in mind that if your organization or team must adhere to the policies of governing bodies, you may need to trade a little speed for greater risk assurance, confidence, quality, got-to-market value, and ROI.

Vague Requirements: Iterative

When stakeholders and agile teams agree to start a development project with vague requirements, there’s greater risk involved. Still, it can be controlled with the right perspective, plan, agreement, and management across iterations.?

The iterative approach to vague requirements is typically handled in very short (1-week cycles) to get feedback faster in gauging if the increment meets a valuable need or requires improvements. Expect changes in this scenario frequently.?

If your team or program is centered around R&D, vague requirements are likely typical for you.?

An example of starting a project with vague requirements with an Iterative approach is explained in a popular, fictitious example using the Mona Lisa by Jeff Patton.

“Iterating allows you to move from a vague idea to realization. Iterating builds a rough version, validates it, then slowly builds up quality. It is not an iteration if you only do it once. We iterate to find the right solution.”

In the depiction below, the only requirements we have is that the stakeholder wants “a painting of a woman in a pastoral setting.” However, we see it achieve an end state with more detail than what we started with, collected as feedback (changes) through three iteration cycles.

Concrete Requirements: Incremental

When stakeholders and agile teams agree to start a development project with concrete requirements, they start with a fully formed idea. However, the term concrete used here only means that the requirements are not abstract. It doesn’t mean that the requirements are perfect, correct, or won’t change.

The approach to a fully formed idea may need less frequent feedback than vague requirements and can be handled in short 2-week cycles. Changes should be expected, though perhaps not as drastic or frequent as you’d have, starting with vague requirements.

An example using an Incremental approach through the iterative cycle is suitable for a fully formed idea. Using the same Mona Lisa example by Jeff Patton:

“Incrementing calls for a fully formed idea. Incrementing builds a bit at a time. Each increment adds more software – sorta like adding bricks to a wall. After lots of increments, you’ve got a big wall.”

In the depiction below, we have all of the requirements to achieve an end state, with the ability to check the accuracy and improve (collect feedback/changes) through three iteration cycles.

Changing Requirements: Iterative and Incremental

Changing requirements will be the norm regardless of whether we start with vague or concrete requirements. Hence, we more often apply a combination of the iterative and incremental approaches in every agile delivery project.

Again using the Mona Lisa, in the depiction below, we see how the iterative and incremental approach can be applied within each iteration to support vague, concrete, and changing requirements throughout the cycle. This is your most likely scenario.

Note: Iteration durations are established based on how quickly you need stakeholder feedback. In the Scrum iterative framework, you can choose 1, 2, 3, or 4-week cycles. It’s uncommon for teams to select 3 and 4-week iterations. However, if you had a gigantic concrete project that would take 12 months to deliver, it might better serve you to get feedback once per month, offering 12 feedback opportunities. (If you chose 1-week sprints for a 12-month project, you’d have 52 feedback loops. The question to ask is, does your project need that many).