Manage Requirements in an Agile Environment

Manage Requirements in an Agile Environment

Agile and requirements management are complementary, not competitors

Analyst's Perspective

The temptation when moving to Agile is to deemphasize good requirements practices in favor of perceived speed. If you're not delivering on the needs of the business then you have failed, regardless of how fast you've gone.

Delivery in Agile doesn't mean you stop needing solid business analysis. In fact, it's even more critical, to ensure your products and projects are adding value. With the rise of Agile, the role of the business analyst has been misunderstood.

As a result, we often throw out the analysis with the bathwater, thinking we'll be just fine without analysis, documentation, and deliberate action, as the speed and dexterity of Agile is enough.

Consequently, what we get is wasted time, money, and effort, with solutions that fail to deliver value, or need to be re-worked to get it right.

The best organizations find balance between these two forces, to align, and gain the benefits of both Agile and business analysis, working in tandem to manage requirements that bring solutions that are "just right".

Vincent Mirabelli
Principal Research Director, Applications Delivery and Management
Info-Tech Research Group

EXECUTIVE BRIEF

Executive Summary

Your Challenge

The process of navigating from waterfall to Agile can be incredibly challenging. And even more problematic; how do you operate your requirements management practices once there? Since there traditionally isn't a role for a business analyst; the traditional keeper of requirements. it isn't like switching on a light.

You likely find yourself struggling to deliver high quality solutions and requirements in Agile. This is a challenge for many organizations, regardless of how long they've leveraged Agile.

But you aren't here for assurances. You're here for answers and help.

Common Obstacles

many organizations and teams face is that there are so busy doing Agile that they fail to be Agile.

Agile was supposed to be the saving grace of project delivery but is misguided in taking the short-term view of "going quickly" at the expense of important elements, such as team formation and interaction, stakeholder engagement and communication, the timing and sequencing of analysis work, decision-making, documentation, and dealing with change.

The idea that good requirements just happen because you have user stories is wrong. So, requirements remain superficial, as you "can iterate later"…but sometimes later never comes, or doesn't come fast enough.

Organizations need to be very deliberate when aligning their Agile and requirements management practices. The work is the same. How the work is done is what changes.

Info-Tech's Approach

Infotech's advice? Why choose? Why have to pick between traditional waterfall and Agile delivery? If Agile without analysis is a recipe for disaster, Agile with analysis is the solution. And how can you leverage the Info-Tech approach to align your Agile and requirements management efforts into a powerful combination?

Manage Requirements in an Agile Environment is your guide.

Use the contents and exercises of this blueprint to gain a shared understanding of the two disciplines, to find your balance in your approach, to define your thresholds, and ultimately, to prepare for new ways of working.

Info-Tech Insight

Agile and requirements management are complementary, not competitors.

The temptation when moving to Agile is to deemphasize good requirements practices in favor of perceived speed. If you're not delivering on the needs of the business, then you have failed, regardless of how fast you've gone.

Insight summary

Overarching insight

Agile and requirements management are complementary, not competitors.

The temptation when moving to Agile is to deemphasize good requirements practices in favor of perceived speed. If you're not delivering on the needs of the business, then you have failed, regardless of how fast you've gone

Phase 1 insight

• The purpose of requirements in waterfall is for approval. The purpose in Agile is for knowledge management, as Agile has no memory.
• When it comes to the Agile manifesto, "over" does not mean "instead of".
• In Agile, the what of business analysis does doesn't change. What does change is the how and when that work happens.

Phase 2 insight

• Understand your uncertainties; it's a great way to decide what level of Agile (if any) is needed.
• Finding your "Goldilocks" zone will take time. Be patient.

Phase 3 insight

• Right-size your governance, based on team dynamics and project complexity. A good referee knows when to step in, and when to let the game flow.
• Agile creates a social contract amongst the team, and with their leaders and organization.
• Documentation needs to be valuable. Do what is acceptable and necessary to move work to future steps. Not documenting also comes with a cost, but one you pay in the future. And that bill will come due, with interest (aka, technical debt, operational inefficiencies, etc.).
• A lack of acceptable documentation makes it more difficult to have agility. You're constantly revalidating your current state (processes, practices and structure) and re-arguing decisions already made. This slows you down more than maintaining documentation ever would.

Phase 4 insight

• Making Agile predictable is hard, because people are not predictable; people are prone to chaos.

There have been many challenges with waterfall delivery

It turns out waterfall is not that great at reducing risk and ensuring value delivery after all

• Lack of flexibility
• Difficulty in measuring progress
• Difficulties with scope creep
• Limited stakeholder involvement
• Long feedback loops

48%
Had project deadlines more than double

85%
Exceeded their original budget by at least 20%

25%
At least doubled their original budget

Source: PPM Express.

Agile was meant to address the shortcomings of waterfall

The wait for solutions was too long for our business partners. The idea of investing significant time, money, and resources upfront, building an exhaustive and complete vision of the desired state, and then waiting months or even years to get that solution, became unpalatable for them. And rightfully so. Once we cast a light on the pains, it became difficult to stay with the status quo. Given that organizations evolve at a rapid pace, what was a pain at the beginning of an initiative may not be so even 6 months later.

Agile became the answer.

Since its' first appearance nearly 20 years ago, Agile has become the methodology of choice for a many of organizations. According to the 15th Annual State of Agile report, Agile adoption within software development teams increased from 37% in 2020 to 86% in 2021.

Adopting Agile led to challenges with requirements

Requirements analysis, design maturity, and management are critical for a successful Agile transformation.

"One of the largest sources of failure we have seen on large projects is an immature Agile implementation in the context of poorly defined requirements."
– "Large Scale IT Projects – From Nightmare to Value Creation"

"Requirements maturity is more important to project outcomes than methodology."
– "Business Analysis Benchmark: Full Report"

"Mature Agile practices spend 28% of their time on analysis and design."
– "Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings"

"There exists a Requirements Premium… organizations using poor practices spent 62% more on similarly sized projects than organizations using the best requirements practices."
– "The Business Case for Agile Business Analysis" - Requirements Engineering Magazine

Strong stakeholder satisfaction with requirements results in higher satisfaction in other areas

N= 324 small organizations from Info-Tech Research Group's CIO Business Vision diagnostic.

Note: High satisfaction was classified as organizations with a score greater or equal to eight and low satisfaction was every organization that scored below eight on the same questions.

Info-Tech's Agile requirements framework

Agile requirements are a balancing act

Collaboration

Many subject matter experts are necessary to create accurate requirements, but their time is limited too.

Communication

Stakeholders should be kept informed throughout the requirements gathering process, but you need to get the right information to the right people.

Documentation

Recording, organizing, and presenting requirements are essential, but excessive documentation will slow time to delivery.

Control

Establishing control points in your requirements gathering process can help confirm, verify, and approve requirements accurately, but stage gates limit delivery.

What changes for the business analyst?

In Agile, the what of business analysis does not change.

What does change is the how and when that work happens.

Business analysts need to focus on six key elements when managing requirements in Agile.

• Team formation and interaction
• Stakeholder engagement and communication
• The timing and sequencing of their work
• Decision-making
• Documentation
• Dealing with change

Where does the business analysis function fit on an Agile team?

Team formation is key, as Agile is a team sport

A business analyst in an Agile team typically interacts with several different roles, including:

• The product owner,
• The Sponsor or Executive
• The development team,
• Other stakeholders such as customers, end-users, and subject matter experts
• The Design team,
• Security,
• Testing,
• Deployment.

How we do our requirements work will change

• Team formation and interaction
• Stakeholder engagement and communication
• The timing and sequencing of their work
• Decision-making
• Documentation
• Dealing with change

As a result, you'll need to focus on;

• Emphasizing flexibility
• Enabling continuous delivery
• Enhancing collaboration and communication
• Developing a user-centered approach

Get stakeholders on board with Agile requirements

1. Stakeholder feedback and management support are key components of a successful Agile Requirements.
2. Stakeholders can see a project's progression and provide critical feedback about its success at critical milestones.
3. Management helps teams succeed by trusting them to complete projects with business value at top of mind and by removing impediments that are inhibiting their productivity.
4. Agile will bring a new mindset and significant numbers of people, process, and technology changes that stakeholders and management may not be accustomed to. Working through these issues in requirements management enables a smoother rollout.
5. Management will play a key role in ensuring long-term Agile requirements success and ultimately rolling it out to the rest of the organization.
6. The value of leadership involvement has not changed even though responsibilities will. The day-to-day involvement in projects will change but continual feedback will ultimately dictate the success or failure of a project.

Measuring your success

Tracking metrics and measuring your progress

As you implement the actions from this Blueprint, you should see measurable improvements in;

• Team and stakeholder satisfaction
• Requirements quality
• Documentation cost

Without sacrificing time to delivery

Info-Tech's methodology for Agile requirements

Blueprint tools and templates

Key deliverable:

Agile Requirements Playbook

A practical playbook for aligning your teams and articulating the guidelines for managing your requirements in Agile

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Documentation Calculator

A tool to help you answer the question: What is the right level of Agile requirements documentation for my organization?

Agile Requirements Assessment

Establishes your current maturity level, defines your target state, and supports planning to get there.

Agile Requirements Workbook

Supporting tools and templates in advancing your Agile requirements practice, to be used with the Agile Requirements Blueprint and Playbook.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks used throughout all four options

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Guided Implementation

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is 10 calls over the course of 4 to 6 months.

Framing Agile and Business Analysis

Phase 1

Framing Agile and Business Analysis

This phase will walk you through the following activities:

• EXERCISE: What do Agile and requirements mean in your organization?
• ASSESSMENT: Agile requirements assessment
• KEY DELIVERABLE: Agile Requirements Playbook

This phase involves the following participants:

• Business analyst and project team
• Stakeholders
• Sponsor/Executive

Managing Requirements in an Agile Environment

Step 1.1

Understand the benefits and limitations of Agile and business analysis

Activities

1.1.1 Define what Agile and business analysis mean in your organization

This step involves the following participants:

• Business analyst and project team
• Sponsor/Executive

Outcomes of this step

• Recognize the benefits and detriments of both Agile and business analysis

Framing Agile and Business Analysis

There have been many challenges with waterfall delivery

It turns out waterfall is not that great at reducing risk and ensuring value delivery after all

• Lack of flexibility
• Difficulty in measuring progress
• Difficulties with scope creep
• Limited stakeholder involvement
• Long feedback loops

48%
Had project deadlines more than double

85%
Exceeded their original budget by at least 20%

25%
At least doubled their original budget

Source: PPM Express.

Business analysis had a clear home in waterfall

Business analysts had historically been aligned to specific lines of business, in support of their partners in their respective domains. Somewhere along the way, the function was moved to IT. Conceptually this made sense, in that it allowed BAs to provide technical solutions to complex business problems. This had the unintended result of lost domain knowledge, and connection to the business.

It all starts with the business. IT enables business goals. The closer you can get to the business, the better.

Business analysts were the main drivers of helping to define the business requirements, or needs, and then decompose those into solution requirements, to develop the best option to solve those problems, or address those needs. And the case for good analysis was clear. The later a poor requirement was caught, the more expensive it was to fix. And if requirements were poor, there was no way to know until much later in the project lifecycle, when the cost to correct them was exponentially higher, to the tune of 10-100x the initial cost.

Adapted from PPM Express. "Why Projects Fail: Business Analysis is the Key".

Agile was meant to address the shortcomings of waterfall

The wait for solutions was too long for our business partners. The idea of investing significant time, money, and resources upfront, building an exhaustive and complete vision of the desired state, and then waiting months or even years to get that solution became unpalatable for them. And rightfully so. Once we cast a light on the pains, it became difficult to stand pat in the current state. And besides, organizations evolve at a rapid pace. What was a pain at the beginning of an initiative may not be so even six months later.

Agile became the answer.

Since its first appearance nearly 20 years ago, Agile has become the methodology of choice for a huge swathe of organizations. According to the 15th Annual State of Agile report, Agile adoption within software development teams increased from 37% in 2020 to 86% in 2021.

To say that's significant is an understatement.

The four core values of Agile helped shift focus

According to the Agile manifesto, "We value. . ."

"…while there is value in the items on the right, we value the items on the left more."

Source: Agilemanifesto, 2001

Agile has made significant inroads in IT and beyond

94% of respondents report using Agile practices in their organization

according to Digital.AI's "The 15th State of Agile Report"

That same report notes a steady expansion of Agile outside of IT, as other areas of the organization seek to benefit from increased agility and responsiveness, including Human Resources, Finance and Marketing.

While it addressed some problems…

"Agile projects are 37% faster to market than [the] industry average"

(Requirements Engineering Magazine, 2017)

• Business requirements documents are massive and unreadable
• Waterfall erects barriers and bottlenecks between the business and the development team
• It's hard to define the solution at the outset of a project
• There's a long turnaround between requirements work and solution delivery
• Locking in requirements dictates an often-inflexible solution. And the costs to make changes tend to add up.

…Implementing Agile led to other challenges

Adopting Agile led to challenges with requirements

Requirements analysis, design maturity, and management are critical for a successful Agile transformation.

"One of the largest sources of failure we have seen on large projects is an immature Agile implementation in the context of poorly defined requirements."
– BCG, 2015

"Requirements maturity is more important to project outcomes than methodology."
– IAG Consulting, 2009.

"Mature Agile practices spend 28% of their time on analysis and design."
– InfoQ, 2017."

"There exists a Requirements Premium… organizations using poor practices spent 62% more on similarly sized projects than organizations using the best requirements practices."
– Requirements Engineering Magazine, 2017

Strong stakeholder satisfaction with requirements results in higher satisfaction in other areas

N= 324 small organizations from Info-Tech Research Group's CIO Business Vision diagnostic.

Note: High satisfaction was classified as organizations with a score greater or equal to eight and low satisfaction was every organization that scored below eight on the same questions.

Agile is being misinterpreted as an opportunity to bypass planning and analysis activities

Agile is a highly effective tool.

This isn't about discarding Agile. It is being used for things completely outside of what was originally intended. When developing products or code, it is in its element. However, outside of that realm, its being used to bypass business analysis activities, which help define the true customer and business need.

Business analysts were forced to adapt and shift focus. Overnight they morphed into product owners, or no longer had a place on the team. Requirements and analysis took a backseat.

The result?

Increased rework, decreased stakeholder satisfaction, and a lot of wasted money and effort.

"Too often, the process of two-week sprints becomes the thing, and the team never gets the time and space to step back and obsess over what is truly needed to delight customers."
Harvard Business Review, 9 April 2021.

Info-Tech Insight

Requirements in Agile are the same, but the purpose of requirements changes.

• The purpose of requirements in waterfall is for stakeholder approval.
• The purpose of requirements in Agile is knowledge management; to maintain a record of the current state.

Many have misinterpreted the spirit of Agile and waterfall

The stated principles of waterfall say nothing of how work is to be linear.

Source: Royce, Dr. Winston W., 1970.

For more on Agile methodology, check out Info-Tech's Agile Research Centre

How did the pendulum swing so far?

Shorter cycles of work made requirements management more difficult. But the answer isn't to stop doing it.

Organizations went from engaging business stakeholders up front, and then not until solution delivery, to forcing those partners to give up their resources to the project. From taking years to deliver a massive solution (which may or may not even still fit the need) to delivering in rapid cycles called sprints.

This tug-of-war is costing organizations significant time, money, and effort.

Your approach to requirements management needs to be centered. We can start to make that shift by better aligning our Agile and business analysis practices. Outside of the product space, Agile needs to be combined with other disciplines (Harvard Business Review, 2021) to be effective.

Agility is important. Though it is not a replacement for approach or strategy (RCG Global Services, 2022). In Agile, team constraints are leveraged because of time. There is a failure to develop new capabilities to address the business needs Harvard Business Review, 2021).

Agility needs analysis.

Agile requirements are a balancing act

Collaboration

Many subject matter experts are necessary to create accurate requirements, but their time is limited too.

Communication

Stakeholders should be kept informed throughout the requirements gathering process, but you need to get the right information to the right people.

Documentation

Recording, organizing, and presenting requirements are essential, but excessive documentation will slow time to delivery.

Control

Establishing control points in your requirements gathering process can help confirm, verify, and approve requirements accurately, but stage gates limit delivery.

Start by defining what the terms mean in your organization

We do this because there isn't even agreement by the experts on what the terms "Agile" and "business analysis" mean, so let's establish a definition within the context of your organization.

1.1.1 What do Agile and business analysis mean in your organization?

Estimated time: 30 Minutes

1. Explore the motivations behind the need for aligning Agile with business analysis. Are there any current challenges related to outputs, outcomes, quality? How can the team and organization align the two more effectively for the purposes of requirements management?
2. Gather the appropriate stakeholders to discuss their definition of the terms "Agile" and "business analysis" It can be related to their experience, practice, or things they've read or heard.
3. Brainstorm and document all shared thoughts and perspectives.
4. Synthesize those thoughts and perspectives into a shared definition of each term, of a sentence or two.
5. Revisit this definition as needed, and as your Agile requirements efforts evolve.

Input

• Challenges and experiences/perspectives related to Agile and business requirements

Output

• A shared definition of Agile and business analysis, to help guide alignment on Agile requirements management

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Build your Agile Requirements Playbook

Keep the outcomes of this blueprint in a single document

Share at the beginning of a new project, as part of team member onboarding, and revisit as your practice matures.

Your Agile Requirements Playbook will include

• Your shared definition of Agile and business analysis for your organization
• The Agile Requirements Maturity Assessment
• A Methodology Selection Matrix
• Agile requirements RACI
• A defined Agile requirements process
• Documentation Calculator
• Your Requirements Repository Information
• Capability Gap List (from current to target state)
• Target State Improvement Roadmap and Action Plan

Step 1.2

Align Agile and Business Analysis Within Your Organization

Activities

1.2.1 Assess your Agile requirements maturity

This step involves the following participants:

• Business Analyst and Project Team
• Stakeholders
• Sponsor/Executive

Outcomes of this step

• Complete the Agile Requirements Maturity Assessment to establish your current and target states

Framing Agile and Business Analysis

Consider the question: "Why Agile?"

What is the driving force behind that decision?

There are many reasons to leverage the power of Agile within your organization, and specifically as part of your requirements management efforts. And it shouldn't just be to improve productivity. That's only one aspect.
Begin by asking, "Why Agile?" Are you looking to improve:

• Time to market
• Team engagement
• Product quality
• Customer satisfaction
• Stakeholder engagement
• Employee satisfaction
• Consistency in delivery of value
• Predictably of your releases

Or a combination of the above?

Info-Tech Insight

Project delivery methodologies aren't either/or. You don't have to be 100% waterfall or 100% Agile. Select the right approach for your project, product, or service.

In the end, your business partners don't want projects delivered faster, they want value faster!

For more on understanding Agile, check out the Implement Agile Practices That Work Blueprint

Responses to a 2019 KPMG survey:

13% said that their top management fully supports Agile transformation.

76% of organizations did not agree that their organization supports Agile culture.

62% of top management believe Agile has no implications for them.

What changes for the business analyst?

Business analysts need to focus on six key elements when managing requirements in Agile.

• Team formation and interaction
• Stakeholder engagement and communication
• The timing and sequencing of their work
• Decision-making
• Documentation
• Dealing with change

In Agile, the what of business analysis does not change.

What does change is the how and when that work happens.

1.2.1 Assess your Agile requirements maturity

1.2.1 Assess your Agile requirements maturity

Estimated time: 30 Minutes

1. Using the Agile Requirements Maturity Assessment, gather all appropriate stakeholders, and discuss and score the current state of your practice. Scoring can be done by:
1. Consensus: Generally better with a smaller group, where the group agrees the score and documents the result
2. Average: Have everyone score individually, and aggregate the results into an average, which is then entered.
3. Weighted Average: As above, but weight the individual scores by individual or line of business to get a weighted average.
2. When current state is complete, revisit to establish target state (or hold as a separate session) using the same scoring approach as in current state.
1. Recognize that there is a cost to maturity, so don't default to the highest score by default.
2. Resist the urge at this early stage to generate ideas to navigate from current to target state. We will re-visit this exercise in Phase 4, once we've defined other pieces of our process and practice.

Input

• Participant knowledge and experience

Output

• A current and target state assessment of your Agile requirements practice

Materials

• Agile Requirements Maturity Assessment

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Tailoring Your Approach

Phase 2

This phase will walk you through the following activities:

• Selecting the appropriate delivery methodology
• Managing your requirements backlog
• Tracing from business need to user story

This phase involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Managing Requirements in an Agile Environment

Step 2.1

Confirm the Best-fit Approach for Delivery

Activities

2.1.1 Confirm your methodology

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• A review of potential delivery methodologies to select the appropriate, best-fit approach to your projects

Confirming you're using the best approach doesn't have be tricky

Selecting the right approach (or confirming you're on the right track) is easier when you assess two key inputs to your project; your level of certainty about the solution, and the level of complexity among the different variables and inputs to your project, such as team experience and training, the number of impacted stakeholders or context. lines of business, and the organizational

Solution certainty refers to the level of understanding of the problem and the solution at the start of the project. In projects with high solution certainty, the requirements and solutions are well defined, and the project scope is clear. In contrast, projects with low solution certainty have vague or changing requirements, and the solutions are not well understood.

Project complexity refers to the level of complexity of the project, including the number of stakeholders, the number of deliverables, and the level of technical complexity. In projects with high complexity, there are many stakeholders with different priorities, many deliverables, and high technical complexity. In contrast, projects with low complexity have fewer stakeholders, fewer deliverables, and lower technical complexity.

"Agile is a fantastic approach when you have no clue how you're going to solve a problem"

• Ryan Folster, Consulting Services Manager, Business Analysis, Dimension Data

Use Info-Tech's methodology selection matrix

Waterfall methodology is best suited for projects with high solution certainty and high complexity. This is because the waterfall model follows a linear and sequential approach, where each phase of the project is completed before moving on to the next. This makes it ideal for projects where the requirements and solutions are well-defined, and the project scope is clear.

On the other hand, Agile methodology is best suited for projects with low solution certainty. Agile follows an iterative and incremental approach, where the requirements and solutions are detailed and refined throughout the project. This makes it ideal for projects where the requirements and solutions are vague or changing.

Note that there are other models that exist for determining which path to take, should this approach not fit within your organization.

Use info-tech's-methodology-selection-matrix

Adapted from The Chaos Report, 2015 (The Standish Group)

Download the Agile Requirements Workbook

2.1.1 Confirm your methodology

Estimated time: 30 Minutes

1. Using the Agile Requirements Workbook, find the tab labelled "Methodology Assessment" and answer the questions to establish your complexity and certainty scores, where;

1 = Strongly disagree
2 = Disagree
3 = Neutral
4 = Agree
5 = Strongly agree.

2. In the same workbook, plot the results in the grid on the tab labelled "Methodology Matrix".
3. Projects falling into Green are good fits for Agile. Yellow are viable. And Red may not be a great fit for Agile.
4. Note: Ultimately, the choice of methodology is yours. Recognize there may be additional challenges when a project is too complex, or uncertainty is high.

Input

• Current project complexity and solution certainty

Output

• A clear choice of delivery methodology

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Step 2.2

Manage Your Requirements Backlog

Activities

2.2.1 Create your user stories

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• Understand how to convert requirements into user stories, which populate the Requirements Backlog.

Tailoring Your Approach

There is a hierarchy to requirements

	Higher-level statements of the goals, objectives, or needs of the enterprise. Business requirements focus on the needs of the organization, and not the stakeholders within it.	Defines
		Intended benefits and outcomes
	Statements of the needs of a particular stakeholder or class of stakeholders, and how that stakeholder will interact with a solution.	Why it is needed, and by who
	Describes the characteristics of a solution that meets business requirements and stakeholder requirements. Functional describes the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations. Non-functional represents constraints on the ultimate solution and tends to be less negotiable.	What is needed, and how its going to be achieved

Connect the dots with a traceability matrix

Business requirements describe what a company needs in order to achieve its goals and objectives. Solution requirements describe how those needs will be met. User stories are a way to express the functionality that a solution will provide from the perspective of an end user.

A traceability matrix helps clearly connect and maintain your requirements.

To connect business requirements to solution requirements, you can start by identifying the specific needs that the business has and then determining how those needs can be met through technology or other solutions; or what the solution needs to do to meet the business need. So, if the business requirement is to increase online sales, a solution requirement might include implementing a shopping cart feature on your company website.

Once you have identified the solution requirements, you can then use those to create user stories. A user story describes a specific piece of functionality that the solution will provide from the perspective of a user.

For example, "As a customer, I want to be able to add items to my shopping cart so that I can purchase them." This user story is directly tied to the solution requirement of implementing a shopping cart feature.

Tracing from User Story back up to Business Requirement is essential in ensuring your solutions support your organization's strategic vison and objectives.

Download the Info-Tech Requirements Traceability Matrix

Improve the quality of your solution requirements

A solution requirement is a statement that clearly outlines the functional capability that the business needs from a system or application.

For more on developing high quality requirements, check out the Improve Requirements Gathering Blueprint

Prioritize your requirements

When everything is a priority, nothing is a priority.

Prioritization is the process of ranking each requirement based on its importance to project success. Each requirement should be assigned a priority level. The delivery team will use these priority levels to ensure efforts are targeted toward the proper requirements as well as to plan features available on each release. Use the MoSCoW Model of Prioritization to effectively order your requirements.

The MoSCoW Model of Prioritization

The MoSCoW model was introduced by Dai Clegg of Oracle UK in 1994

(Source: ProductPlan).

Base your prioritization on the right set of criteria

Info-Tech Insight

It is easier to prioritize requirements if they have already been collapsed, resolved, and rewritten. There is no point in prioritizing every requirement that is elicited up front when some of them will eventually be eliminated.

Manage solution requirements in a Product backlog

What is a backlog?

Agile teams are familiar with the use of a Sprint Backlog, but in Requirements Management, a Product Backlog is a more appropriate choice.

A product backlog and a Sprint backlog are similar in that they are both lists of items that need to be completed in order to deliver a product or project, but there are some key differences between the two.

A product backlog is a list of all the features, user stories, and requirements that are needed for a product or project. It is typically created and maintained by the business analyst or product owner and is used to prioritize and guide the development of the product.

A Sprint backlog, on the other hand, is a list of items specifically for an upcoming sprint, which is an iteration of work in Scrum. The Sprint backlog is created by the development team and is used to plan and guide the work that will be done during the sprint. The items in the Sprint backlog are typically taken from the product backlog and are prioritized based on their importance and readiness.

For more on building effective product backlogs, visit Deliver on Your Digital Product Vision

A backlog stores and organizes requirements at various stages

Your backlog must give you a holistic understanding of demand for change in the product.

A well-formed backlog can be thought of as a DEEP backlog

Detailed appropriately: Requirements are broken down and refined as necessary

Emergent: The backlog grows and evolves over time as requirements are added and removed.

Estimated: The effort to deliver a requirement is estimated at each tier.

Prioritized: A requirement's value and priority are determined at each tier.

Adapted from Essential Scrum

Ensure requests and requirements are ready for development

Clearly define what it means for a requirement, change, or maintenance request to be ready for development.

This will help ensure the value and scope of each functionality and change are clear and well understood by both developers and stakeholders before the start of the sprint. The definition of ready should be two-fold: ready for the backlog, and ready for coding.

1. Create a checklist that indicates when a requirement or request is ready for the development backlog. Consider the following questions:
1. Is the requirement or request in the correct format?
2. Does the desired functionality or change have significant business value?
3. Can the requirement or request be reasonably completed within defined release timelines under the current context?
4. Does the development team agree with the budget and points estimates?
5. Is there an understanding of what the requirement or request means from the stakeholder or user perspective?
2. Create a checklist that indicates when a requirement or request is ready for development. Consider the following questions:
1. Have the requirements and requests been prioritized in the backlog?
2. Has the team sufficiently collaborated on how the desired functionality or change can be completed?
3. Do the tasks in each requirement or request contain sufficient detail and direction to begin development?
4. Can the requirement or request be broken down into smaller pieces?

Converting solution requirements into user stories

Define the user

Who will be interacting with the product or feature being developed? This will help to focus the user story on the user's needs and goals.

Create the story

Create the user story using the following template: "As a [user], I want [feature] so that [benefit]."
This helps articulate the user's need and the value that the requirement will provide.

Decompose

User stories are typically too large to be implemented in a single sprint, so they should be broken down into smaller, more manageable tasks.

Prioritize

User stories are typically too large to be implemented in a single sprint, so they should be broken down into smaller, more manageable tasks.

2.2.1 Create your user stories

Estimated time: 60 Minutes

1. Gather the project team and relevant stakeholders. Have access to your current list of solution requirements.
2. Leverage the approach on previous slide "Converting Solution Requirements into User Stories" to generate a collection of user stories.

NOTE: There is not a 1:1 relationship between requirements and user stories.
It is possible that a single requirement will have multiple user stories, and similarly, that a single user story will apply to multiple solution requirements.

Input

• Requirements
• Use Case Template

Output

• A collection of user stories

Materials

• Current Requirements

Participants

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Use the INVEST model to create good user stories

At this point your requirements should be high-level stories. The goal is to refine your backlog items, so they are . . .

Independent: Ideally your user stories can be built in any order (i.e. independent from each other). This allows you to prioritize based on value and not get caught up in sequencing and prerequisites. Negotiable: As per the Agile principle, collaboration over contracts. Your user stories are meant to facilitate collaboration between the developer and the business. Therefore, they should be built to allow negotiation between all parties. Valuable: A user story needs to state the value so it can be effectively prioritized, but also so developers know what they are building. Estimable: As opposed to higher-level approximation given to epics, user stories need more accuracy in their estimates in order to, again, be effectively prioritized, but also so teams can know what can fit into a sprint or release plans. Small: User stories should be small enough for a number of them to fit into a sprint. However, team size and velocity will impact how many can be completed. A general guideline is that your teams should be able to deliver multiple stories in a sprint. Testable: Your stories need to be testable, which means they must have defined acceptance criteria and any related test cases as defined in your product quality standards. Source: Agile For All

Defining Your Requirements Thresholds

Phase 3

Defining Your Requirements Thresholds

This phase will walk you through the following activities:

• Assigning roles and responsibilities optional (Tool: RACI)
• Define your Agile requirements process
• Calculate the cost of your documentation (Tool: Documentation Calculator)
• Define your backlog refinement plan

This phase involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Managing Requirements in an Agile Environment

Step 3.1

Define Project Roles and Responsibilities

Activities

3.1.1 Define your Agile requirements RACI (optional)

3.1.2 Define your Agile requirements process

Defining Your Requirements Thresholds

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• A defined register of roles and responsibilities, along with a defined process for how Agile requirements work is to be done.

Defining Your Requirements Thresholds

Where does the BA function fit on an Agile team?

Team formation is key, as Agile is a team sport

A business analyst in an Agile team typically interacts with several different roles, including the product owner, development team, and many other stakeholders throughout the organization.

• The product owner, to set the priorities and direction of the project, and to gather requirements and ensure they are being met. Often, but not always, the BA and product owner are the same individual.
• The development team, to provide clear and concise requirements that they can use to build and test the product.
• Other stakeholders, such as customers, end-users, and subject matter experts to gather their requirements, feedback and validate the solution.
  • Design, to ensure that the product meets user needs. They may provide feedback and ensure that the design is aligned with requirements.
  • Security, to ensure that the solution meets all necessary security requirements and to identify potential risks and appropriate use of controls.
  • Testing, to ensure that the solution is thoroughly tested before it is deployed. They may create test cases or user scenarios that validate that everything is working as intended.
  • Deployment, to ensure that the necessary preparations have been made, including testing, security, and user acceptance.

Additionally, during the sprint retrospectives, the team will review their performance and find ways to improve for the next sprint. As a team member, the business analyst helps to identify areas where the team could improve how they are working with requirements and understand how the team can improve communication with stakeholders.

3.1.1 (Optional) Define Your Agile Requirements RACI

Estimated Time: 60 Minutes

1. Identify the project deliverables: The first step is to understand the project deliverables and the tasks that are required to complete them. This will help you to identify the different roles and responsibilities that need to be assigned.
2. Define the roles and responsibilities: Identify the different roles that will be involved in the project and their associated responsibilities. These roles may include project manager, product owner, development team, stakeholders, and any other relevant parties.
3. Assign RACI roles: Assign a RACI role to each of the identified tasks. The RACI roles are:
1. Responsible: the person or team who is responsible for completing the task
2. Accountable: the person who is accountable for the task being completed on time and to the required standard
3. Consulted: the people or teams who need to be consulted to ensure the task is completed successfully
4. Informed: the people or teams who need to be informed of the task's progress and outcome
4. Create the RACI chart: Use the information gathered in the previous steps to create a matrix or chart that shows the tasks, the roles, and the RACI roles assigned to each task.
5. Review and refine: Review the RACI chart with the project team and stakeholders to ensure that it accurately reflects the roles and responsibilities of everyone involved. Make any necessary revisions and ensure that all parties understand their roles and responsibilities.
6. Communicate and implement: Communicate the RACI chart to all relevant parties and ensure that it is used as a reference throughout the project. This will help to ensure that everyone understands their role and that tasks are completed on time and to the required standard.

Input

• A list of required tasks and activities
• A list of stakeholders

Output

• A list of defined roles and responsibilities for your project

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

A Case Study in Team Formation

Industry: Anonymous Organization in the Energy sector
Source: Interview

Challenge

Agile teams were struggling to deliver within a defined sprint, as there were consistent delays in requirements meeting the definition of ready for development. As such, sprints were often delayed, or key requirements were descoped and deferred to a future sprint.

During a given two-week sprint cycle, the business analyst assigned to the team would be working along multiple horizons, completing elicitation, analysis, and validation, while concurrently supporting the sprint and dealing with stakeholder changes.

Solution

As a part of addressing this ongoing pain, a pilot program was run to add a second business analyst to the team.

The intent was, as one is engaged preparing requirements through elicitation, analysis, and validation for a future sprint, the second is supporting the current sprint cycle, and gaining insights from stakeholders to refine the requirements backlog.

Essentially, these two were leap-frogging each other in time. At all times, one BA was focused on the present, and one on the future.

Result

A happier team, more satisfied stakeholders, and consistent delivery of features and functions by the Agile teams. The pilot team outperformed all other Agile teams in the organization, and the "2 BA" approach was made the new standard.

Understanding the Agile requirements process

Shorter cycles make effective requirements management more necessary, not less

Short development cycles can make requirements management more difficult because they often result in a higher rate of change to the requirements. In a shorter timeframe, there is less time to gather and verify requirements, leading to a higher likelihood of poor or incomplete requirements. Additionally, there may be more pressure to make decisions quickly, which can lead to less thorough analysis and validation of requirements. This can make it more challenging to ensure that the final solution meets the needs of the stakeholders.
When planning your requirements cycles, it's important to consider;

• Your sprint logistics (how long?)
• Your release plan (at the end of every sprint, monthly, quarterly?)
• How the backlog will be managed (as tickets, on a visual medium, such as a Kanban board?)
• How will you manage communication?
• How will you monitor progress?
• How will future sprint planning happen?

Info-Tech's Agile requirements framework

	Sprint N(-1)	Sprint N	Sprint N(+1)
Changes from waterfall to Agile	Gathering and documenting requirements: Requirements are discovered and refined throughout the project, rather than being gathered and documented up front. This can be difficult for business analysts who are used to working in a waterfall environment where all requirements are gathered and documented before development begins. Prioritization of requirements: Requirements are prioritized based on their value to the customer and the team's ability to deliver them. This can be difficult for business analysts who are used to prioritizing requirements based on the client's needs or their own understanding of what is important.	Defining acceptance criteria: Acceptance criteria are defined for each user story to ensure that the team understands what needs to be delivered. Business analysts need to understand how to write effective acceptance criteria and how to use them to ensure that the team delivers what the customer needs. Supporting Testing and QA: The business analyst plays a role in ensuring that testing (and test cases) are completed and of proper quality, as defined in the requirements.	Managing changing requirements: It is expected that requirements will change throughout the project. Business analysts need to be able to adapt quickly to changing requirements and ensure that the team is aware of the changes and how they will impact the project. Collaboration with stakeholders: Requirements are gathered from a variety of stakeholders, including customers, users, and team members. Business analysts need to be able to work effectively with all stakeholders to gather and refine requirements and ensure that the team is building the right product.

3.1.2 Define your Agile requirements process

Estimated time: 60 Minutes

1. Gather all relevant stakeholders to discuss and define your process for requirements management.
2. Have a team member facilitate the session to define the process. The sample in the Agile Requirements Workbook can be used optionally as a starting point. You can also use any existing processes and procedures as a baseline.
3. Gain agreement on the process from all involved stakeholders.
4. Revisit the process periodically to review its performance and make adjustments as needed.

NOTE: The process is intended to be at a high enough level to leave space and flexibility for team members to adapt and adjust, but at a sufficient depth that everyone understands the process and workflows. In other words, the process will be both flexible and rigid, and the two are not mutually exclusive.

Input

• Project team and RACI
• Existing Process (if available)

Output

• A process for Agile requirements that is flexible yet rigid

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Establish the right level of governance and decision-making

Establishing the right level of governance and decision making is important in Agile requirements because there is a cost to decision making, as time plays an important factor. Even the failure to decide can have significant impacts.

Good governance and decision-making practices can help to minimize risks, ensure that requirements are well understood and managed, and that project progress is tracked and reported effectively.

In Agile environments, this often involves establishing clear roles and responsibilities, implementing effective communication and collaboration practices, and ensuring that decision-making processes are efficient and effective.

Good requirements management practices can help to ensure that projects are aligned with organizational goals and strategy, that stakeholders' needs are understood and addressed, and that deliverables are of high quality and meet the needs of the business.

By ensuring that governance and decision-making is effective, organizations can improve the chances of project success, and deliver value to the business. Risks and costs can be mitigated by staying small and nimble.

Check out Make Your IT Governance Adaptable

Develop an adaptive governance process

Maturing governance is a journey

Organizations should look to progress in their governance stages. Ad-hoc and controlled governance tends to be slow, expensive, and a poor fit for modern practices.

The goal as you progress through your stages is to delegate governance and empower teams to make optimal decisions in real-time, knowing that they are aligned with the understood best interests of the organization.

Automate governance for optimal velocity, while mitigating risks and driving value.

This puts your organization in the best position to be adaptive and able to react effectively to volatility and uncertainty.

Five key principles for building an adaptive governance framework

Delegate and empower

Decision making must be delegated down within the organization, and all resources must be empowered and supported to make effective decisions.

Define outcomes

Outcomes and goals must be clearly articulated and understood across the organization to ensure decisions are in line and stay within reasonable boundaries.

Make risk- informed decisions

Integrated risk information must be available with sufficient data to support decision making and design approaches at all levels of the organization.

Embed / automate

Governance standards and activities need to be embedded in processes and practices. Optimal governance reduces its manual footprint while remaining viable. This also allows for more dynamic adaptation.

Establish standards and behavior

Standards and policies need to be defined as the foundation for embedding governance practices organizationally. These guardrails will create boundaries to reinforce delegated decision making.

Sufficient decision-making power should be given to your Agile teams

Push the decision-making process down to your pilot teams.

• Bring your business stakeholders and subject matter experts together to identify the potential high-level risks.
• Bring your business stakeholders and subject matter experts together to identify the potential high-level risks.
• Discuss with the business the level of risk they are willing to accept.
• Define the level of authority project teams have in making critical decisions.

"Push the decision making down as far as possible, down to the point where sprint teams completely coordinate all the integration, development, and design. What I push up the management chain is risk taking. [Management] decides what level of risk they are willing to take and [they] demonstrate that by the amount of decision making you push down."
– Senior Manager, Canadian P&C Insurance Company, Info-Tech Interview

Step 3.2

Define Your Level of Acceptable Documentation

Activities

3.2.1 Calculate the cost of documentation

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Outcomes of this step

• Quantified cost of documentation produced for your Agile project.

Defining Your Requirements Thresholds

Right-size Your Documentation

Why do we need it, and what purpose does it serve?

Before creating any documentation, consider why; why are you creating documentation, and what purpose is it expected to serve?
Is it:

• … to gain approval?
• … to facilitate decision-making?
• .. to allow the team to think through a challenge or compare solution options?

Next, consider what level of documentation would be acceptable and 'enough' for your stakeholders. Recognize that 'enough' will depend on your stakeholder's personal definition and perspective.
There may also be considerations for maintaining documentation for the purposes of compliance, and auditability in some contexts and industries.
The point is not to eliminate all documentation, but rather, to question why we're producing it, so that we can create just enough to deliver value.

"What does the next person need to do their work well, to gain or create a shared understanding?"
- Filip Hendrickx, Innovating BA and Founder, altershape

Documentation comes at a cost

We need to quantify the cost of documentation, against the expected benefit

All things take time, and that would imply that all things have an inherent cost. We often don't think in these terms, as it's just the work we do, and costs are only associated with activities requiring additional capital expenditure. Documentation of requirements can come at a cost in terms of time and resources. Creating and maintaining detailed documentation requires effort from project team members, which could be spent on other aspects of the project such as development or testing. Additionally, there may be costs associated with storing and distributing the documentation.

When creating documentation, we are making a decision. There is an opportunity cost of investing time to create, and concurrently, not working on other activities. Documentation of requirements can come at a cost in terms of time and resources. Creating and maintaining detailed documentation requires effort from project team members, which could be spent on other aspects of the project such as development or testing. Additionally, there may be costs associated with storing and distributing the documentation.

In order to make better informed decisions about the types, quantity and even quality of the documentation we are producing, we need to capture that data. To ensure we are receiving good value for our documentation, we should compare the expected costs to the expected benefits of a sprint or project.

3.2.1 Calculate the cost of documentation

Estimated time: as needed

1. Use this tool to quantify the cost of creating and maintaining current state documentation for your Agile requirements team. It provides an indication, via the Documentation Cost Index, of when your project is documenting excessively, relative to the expected benefits of the sprint or project.
2. In Step 1, enter the hourly rate for the person (or persons) completing the business analysis function for your Agile team. NB: This does not have to be a person with the title of business analyst. If there are multiple people fulfilling this role, enter the average rate (if their rates are same or similar) or a weighted average (if there is a significant range in the hourly rate)
3. In Step 2, enter the expected benefit (in $) for the sprint or project.
4. In Step 3, enter the total number of hours spent on each task/activity during the sprint or project. Use blank spaces as needed to add tasks and activities not listed.
5. In Step 4, you'll find the Documentation Cost Index, which compares your total documentation cost to the expected benefits. The cell will show green when the value is < 0.8, yellow between 0.8 and 1, and red when >1.
6. Use the information to plan future sprints and documentation needs, identify opportunities for improvement in your requirements practice, and find balance in "just enough" documentation.

Input

• Project team and RACI
• Existing Process (if available)

Output

• A process for Agile requirements that is flexible yet rigid

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Lack of documentation also comes at a cost

Lack of documentation can bring costs to Agile projects in a few different ways.

• Onboarding new team members
• Improving efficiency
• Knowledge management
• Auditing and compliance
• Project visibility
• Maintaining code

Info-Tech Insight

Re-using deliverables (documentation, process, product, etc.) is important in maintaining the velocity of work. If you find yourself constantly recreating your current state documentation at the start of a project, it's hard to deliver with agility.

Step 3.3

Manage Requirements as an Asset

Activities

3.3.1 Discuss your current perspectives on requirements as assets

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Outcomes of this step

• Awareness of the value in, and tactics for enabling effective management of requirements as assets

Defining Your Requirements Thresholds

What do we mean by "assets"?

And when do requirements become assets?

In order to delivery with agility, you need to maximize the re-usability of artifacts. These artifacts could take the form of current state documentation, user stories, test cases, and yes, even requirements for re-use.
Think of it like a library for understanding where your organization is today. Understanding the people, processes, and technology, in one convenient location. These artifacts become assets when we choose to retain them, rather than discard them at the end of a project, when we think they'll no longer be needed.
And just like finding a single book in a vast library, we need to ensure our assets can be found when we need them. And this means making them searchable.
We can do this by establishing criteria for requirements and artifact reuse;

• What business need and benefit is it aligned to?
• What metadata needs to be attached, related to source, status, subject, author, permissions, type, etc.?
• Where will it be stored for ease of retrieval?

Info-Tech Insight

When writing requirements for products or services, write them for the need first, and not simply for what is changing.

The benefits of managing requirements as assets

Retention of knowledge in a knowledge base that allows the team to retain current business requirements, process documentation, business rules, and any other relevant information.
A clearly defined scope to reduce stakeholder, business, and compliance conflicts.
Impact analysis of changes to the current organizational assets.

Source: Requirement Engineering Magazine, 2017.

A case study in creating an asset repository

Industry: Anonymous Organization in the Government sector
Source: Interview

Challenge

A large government organization faced a challenge with managing requirements, processes, and project artifacts with any consistency.

Historically, their documentation was lacking, with multiple versions existing in email sent folders and manila folders no one could find. Confirming the current state at any given time meant the heavy lift of re-documenting and validating, so that effort was avoided for an excessive period.

Then there was a request for audit and compliance, to review their existing documentation practices. With nothing concrete to show, drastic recommendations were made to ensure this practice would end.

Solution

A small but effective team was created to compile and (if not available) document all existing project and product documentation, including processes, requirements, artifacts, business cases, etc.

A single repository was built and demonstrated to key stakeholders to ensure it would satisfy the needs of the audit and compliance group.

Result

A single source of truth for the organization, which was;

• Accessible (view access to the entire organization).
• Transparent (anyone could see and understand the process and requirements as intended).
• A baseline for continuous improvement, as it was clear what the one defined "best way" was.
• Current, where no one retained current documentation outside of this library.

3.3.1 Discuss your current perspectives on requirements as assets

Estimated time: 30 Minutes

1. Gather all relevant stakeholder to share perspectives on the use of requirements as assets, historically in the organization.
2. Have a team member facilitate the session. It is optional to document the findings.
3. After looking at the historical use of requirements as assets, discuss the potential uses, benefits, and drawbacks of managing as assets in the target state.

Input

• Participant knowledge and experience

Output

• A shared perspective and history on requirements as assets

Materials

• A method for data capture (optional)

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Apply changes to baseline documentation

Baseline + Release Changes = New Baseline

• Start from baseline documentation dramatically to reduce cost and risk
• Treat all scope as changes to baseline requirements
• Sum of changes in the release scope
• Sum of changes and original baseline becomes the new baseline
• May take additional time and effort to maintain accurate baseline

What is the right tool?

While an Excel spreadsheet is great to start off, its limitations will become apparent as your product delivery process becomes more complex. Look at these solutions to continue your journey in managing your Agile requirements:

Step 3.4

Define Your Requirements Change Management Plan

Activities

3.4.1 Triage your requirements

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Outcomes of this step

• An approach for determining the appropriate level of governance over changes to requirements.

Expect and embrace change

In Agile development, change is expected and embraced. Instead of trying to rigidly follow a plan that may become outdated, Agile teams focus on regularly reassessing their priorities and adapting their plans accordingly. This means that the requirements can change often, and it's important for the team to have a process in place for managing these changes.

A common approach to managing change in Agile is to use a technique called "backlog refinement." Where previously we populated our backlog with requirements to get them ready for development and deployment, this involves regularly reviewing and updating the list of work to be done. The team will prioritize the items on the evolving backlog, and the prioritized items will be worked on during the next sprint. This allows the team to quickly respond to changes in requirements and stay focused on the most important work.

Another key aspect of managing change in Agile is effective communication. The team should have regular meetings, such as daily stand-up meetings or weekly sprint planning meetings, to discuss any changes in requirements and ensure that everyone is on the same page.

Best practices in change and backlog refinement

Communicate

Clearly communicate your change process, criteria, and any techniques, tools, and templates that are part of your approach.

Understand impacts/risks

Maintain consistent control and communication and ensure that an impact assessment is completed. This is key to managing risks.

Leverage tools

Leverage tools when you have them available. This could be a Requirements Management system, a defect/change log, or even by turning on "track changes" in your documents.

Cross-reference

For every change, define the source of the change, the reason for the change, key dates for decisions, and any supporting documentation.

Communicate the reason, and stay on message throughout the change

Leaders of successful change spend considerable time developing a powerful change message: a compelling narrative that articulates the desired end state and makes the change concrete and meaningful to staff. They create the change vision with staff to build ownership and commitment.

• The change message should:
• Explain why the change is needed.
• Summarize the things that will stay the same.
• Highlight the things that will be left behind.
• Emphasize the things that are being changed.
• Explain how the change will be implemented.
• Address how the change will affect the various roles in the organization.
• Discuss staff's role in making the change successful.

The five elements of communicating the reason for the change:

How to make the management of changes more effective

Key decisions and considerations

How will changes to requirements be codified?
How will intake happen?

• What is the submission process?
• Who has approval to submit?
• What information is needed to submit a request?

How will potential changes be triaged and evaluated?

• What criteria will be used to assess the impact and urgency of the potential change?
• How will you treat material and non-material changes?

What is the review and approval process?

• How will acceptance or rejection status be communicated to the submitter?

3.4.1 Triage Your requirements

If there's no material impact, update and move on

Material changes require oversight and approval

Planning Your Next Steps

Phase 4

Planning Your Next Steps

This phase will walk you through the following activities:

• Completing Your Agile Requirements Playbook
• EXERCISE: Capability Gap List

This phase involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Managing Requirements in an Agile Environment

Step 4.1

Preparing New Ways of Working

Activities

4.1.1 Define your communication plan

Planning Your Next Steps

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• Recognize the changes required on the team and within the broader organization, to bring stakeholders on board.

How we do requirements work will change

Change within the team, and in the broader organization

How to build an effective blend Agile and requirements management

Within the team

• Meetings should happen as needed
• Handoffs should be clear and concise
• Interactions should add value
• Stand-ups should similarly add value, and shouldn't be for status updates

Within the organization

• PMO inclusion, to ensure alignment across the organization
• Business/Operating areas, to recognize what they are committing to for time, resources, etc.
• Finance, for how your project or product is funded
• Governance and oversight, to ensure velocity is maintained

"Whether in an Agile environment or not, collaboration and relationships are still required and important…how you collaborate, communicate, and how you build relationships are key."
- Paula Bell, CEO, Paula A. Bell Consulting

Get stakeholders on board with Agile requirements

1. Stakeholder feedback and management support are key components of successful Agile requirements.
2. Stakeholders can see a project's progression and provide critical feedback about its success at critical milestones.
3. Management helps teams succeed by trusting them to complete projects with business value at top of mind and by removing impediments that are inhibiting their productivity.
4. Agile will bring a new mindset and significant amounts of people, process, and technology changes that stakeholders and management may not be accustomed to. Working through these issues in requirements management enables a smoother rollout.
5. Management will play a key role in ensuring long-term Agile requirements success and ultimately rolling it out to the rest of the organization.
6. The value of leadership involvement has not changed even though responsibilities will. The day-to-day involvement in projects will change but continual feedback will ultimately dictate the success or failure of a project.

4.1.1 Define your communication plan

Estimated time: 60 Minutes

1. Gather all relevant stakeholder to create a communication plan for project or product stakeholders.
2. Have a team member facilitate the session.
3. Identify
4. ;
1. Each stakeholder
2. The nature of information they are interested in
3. The channel or medium best to communicate with them
4. The frequency of communication
5. (Optional) Consider validating the results with the stakeholders, if not present.
6. Document the results in the Agile Requirements Workbook and include in Agile Requirements Playbook.
7. Revisit as needed, whether at the beginning of a new initiative, or over time, to ensure the content is still valid.

Input

• Participant knowledge and experience

Output

• A plan for communicating with stakeholders

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team

Step 4.2

Develop a Roadmap for Next Steps

Activities

4.2.1 Develop your Agile requirements action plan

4.2.2 Prioritize with now, next, later

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• A comprehensive and prioritized list of opportunities and improvements to be made to mature the Agile requirements practice.

Planning Your Next Steps

Identify opportunities to improve and close gaps

Maturing at multiple levels

With a mindset of continuous improvement, there is always some way we can get better.

As you mature your Agile requirements practice, recognize that those gaps for improvement can come from multiple levels, from the organizational down to the individual.

Each level will bring challenges and opportunities.

The organization

• Organizational culture
• Organizational behavior
• Political will
• Unsupportive stakeholders

The team

• Current ways of working
• Team standards, norms and values

The individual

• Practitioner skills
• Practitioner experience
• Level of training received

Make sure your organization is ready to transition to Agile requirements management

	Learning: Agile is a radical change in how people work and think. Structured, facilitated learning is required throughout the transformation to help leaders and practitioners go from doing Agile to being Agile.
	Automation: While Agile is tool-agnostic at its roots, Agile work management tools and DevOps inspired SDLC tools that have become a key part of Agile practices.
	Integrated Teams: While temporary project teams can get some benefits from Agile, standing, self-organizing teams that cross business, delivery, and operations are essential to gain the full benefits of Agile.
	Metrics and Governance: Successful Agile implementations require the disciplined use of delivery and operations metrics that support governance focused on developing better teams.
	Culture: Agile teams believe that value is best created by standing, self-organizing cross-functional teams who deliver sustainably in frequent, short increments supported by leaders who coach them through challenges.

Info-Tech Insight

Agile gaps may only have a short-term, perceived benefit. For example, coding without a team mindset can allow for maximum speed to market for a seasoned developer. Post-deployment maintenance initiatives, however, often lock the single developer as no one else understands the rationale for the decisions that were made.

4.2.1 Develop your Agile requirements action plan

Estimated time: 60 Minutes

1. Gather all relevant stakeholder to create a road map and action plan for requirements management.
2. Have a team member facilitate the session using the results of the Agile Requirements Maturity Assessment.
3. Identify gaps from current to future state and brainstorm possible actions that can be taken to address those gaps. Resist the urge to analyze or discuss the feasibility of each idea at this stage. The intent is idea generation.
4. When the group has exhausted all ideas, the facilitator should group like ideas together, with support from participants. Discuss any ideas that are unclear or ambiguous.
5. Document the results in the Agile Requirements Workbook.

Note: the feasibility and timing of the ideas will happen in the following "Now, Next, Later" exercise.

Prioritize your roadmap

Taking steps to mature your Agile requirements practice.

The "Now, Next, Later" technique is a method for prioritizing and planning improvements or tasks. This involves breaking down a list of tasks or improvements into three categories: "Now" tasks are those that must be completed immediately. These tasks are usually urgent or critical, and they must be completed to keep the project or organization running smoothly. "Next" tasks are those that should be completed soon. These tasks are not as critical as "now" tasks, but they are still important and should be tackled relatively soon. "Later" tasks are those that can be completed later. These tasks are less critical and can be deferred without causing major problems. By using this technique, you can prioritize and plan the most important tasks first, while also allowing for flexibility and the ability to adjust plans as necessary. This process also helps you get a clear picture on what needs to be done first and what can be done later. This way you can work on the most important things first, and keep track of what you need to do next, for keeping the development/improvement process smooth and efficient.

Monitor your progress

Monitoring progress is important in achieving your target state. Be deliberate with your actions, to continue to mature your Agile requirements practice.

As you navigate toward your target state, continue to monitor your progress, your successes, and your challenges. As your Agile requirements practice matures, you should see improvements in the stated metrics below.

Establish a cadence to review these metrics, as well as how you are progressing on your roadmap, against the plan.

This is not about adding work, but rather, about ensuring you're heading in the right direction; finding the balance in your Agile requirements practice.

Appendix

Research Contributors and Experts

Emal Bariali
Business Architect & Business Analyst
Bariali Consulting

Emal Bariali is a Senior Business Analyst and Business Architect with 17 years of experience, executing nearly 20 projects. He has experience in both waterfall and Agile methodologies and has delivered solutions in a variety of forms, including custom builds and turnkey projects. He holds a Master's degree in Information Systems from the University of Toronto, a Bachelor's degree in Information Technology from York University, and a post-diploma in Software & Database Development from Seneca College.

Paula Bell
Paula A. Bell Consulting, LLC

Paula Bell is the CEO of Paula A Bell Consulting, LLC. She is a Business Analyst, Leadership and Career Development coach, consultant, speaker, and author with 21+ years of experience in corporate America in project roles including business analyst, requirements manager, business initiatives manager, business process quality manager, technical writer, project manager, developer, test lead, and implementation lead. Paula has experience in a variety of industries including media, courts, manufacturing, and financial. Paula has led multiple highly-visible multi-million-dollar technology and business projects to create solutions to transform businesses as either a consultant, senior business analyst, or manager.

Currently she is Director of Operations for Bridging the Gap, where she oversees the entire operation and their main flagship certification program.

Ryan Folster
Consulting Services Manager, Business Analysis
Dimension Data

Ryan Folster is a Business Analyst Lead and Product Professional from Johannesburg, South Africa. His strong focus on innovation and his involvement in the business analysis community have seen Ryan develop professionally from a small company, serving a small number of users, to large multi-national organizations. Having merged into business analysis through the business domain, Ryan has developed a firm grounding and provides context to the methodologies applied to clients and projects he is working on. Ryan has gained exposure to the Human Resources, Asset Management, and Financial Services sectors, working on projects that span from Enterprise Line of Business Software to BI and Compliance.

Ryan is also heavily involved in the local chapter of IIBA®; having previously served as the chapter president, he currently serves as a non-executive board member. Ryan is passionate about the role a Business Analyst plays within an organization and is a firm believer that the role will develop further in the future and become a crucial aspect of any successful business.

Filip Hendrickx
Innovating BA, Visiting Professor @ VUB
altershape

Filip loves bridging business analysis and innovation and mixes both in his work as speaker, trainer, coach, and consultant.

As co-founder of the BA & Beyond Conference and IIBA Brussels Chapter president, Filip helps support the BA profession and grow the BA community in and around Belgium. For these activities, Filip received the 2022 IIBA® EMEA Region Volunteer of the Year Award.

Together with Ian Richards, Filip is the author ofBrainy Glue, a business novel on business analysis, innovation and change. Filip is also co-author of the BCS book Digital Product Management and Cycles, a book, method and toolkit enabling faster innovation.

Fabricio Laguna
Professional Speaker, Consultant, and Trainer
TheBrazilianBA.com

Fabrício Laguna, aka The Brazilian BA, is the main reference on business analysis in Brazil. Author and producer of videos, articles, classes, lectures, and playful content, he can explain complex things in a simple and easy-to-understand way. IIBA Brazil Chapter president between 2012-2022. CBAP, AAC, CPOA, PMP, MBA. Consultant and instructor for more than 25 years working with business analysis, methodology, solution development, systems analysis, project management, business architecture, and systems architecture. His online courses are approved by students from 65 countries.

Ryland Leyton
Business Analyst and Agile Coach
Independent Consultant

Ryland Leyton, CBAP, PMP, CSM, is an avid Agile advocate and coach, business analyst, author, speaker, and educator. He has worked in the technology sector since 1998, starting off with database and web programming, gradually moving through project management and finding his passion in the BA and Agile fields. He has been a core team member of the IIBA Extension to the BABOK and the IIBA Agile Analysis Certification. Ryland has written popular books on agility, business analysis, and career. He can be reached at www.RylandLeyton.com.

Steve Jones
Supervisor, Market Support Business Analysis
ISO New England

Steve is a passionate analyst and BA manager with more than 20 years of experience in improving processes, services and software, working across all areas of software development lifecycle, business change and business analysis. He rejoices in solving complex business problems and increasing process reproducibility and compliance through the application of business analysis tools and techniques.

Steve is currently serving as VP of Education for IIBA Hartford. He is a CBAP, certified SAFe Product Owner/Product Manager, Six Sigma Green Belt, and holds an MS in Information Management and Communications.

Angela Wick
Founder
BA-Squared and BA-Cube

Founder of BA-Squared and BA-Cube.com, Angela is passionate about teaching practical, modern product ownership and BA skills. With over 20 years' experience she takes BA skills to the next level and into the future!
Angela is also a LinkedIn Learning instructor on Agile product ownership and business analysis, an IC-Agile Authorized Trainer, Product Owner and BA highly-rated trainer, highly-rated speaker, sought-after workshop facilitator, and contributor to many industry publications, including:

• IIBA BABOK v3 Core Team, leading author on the BABOK v3
• Expert Reviewer, IIBA Agile Extension to the BABOK
• PMI BA Practice Guide – Expert Reviewer
• PMI Requirements Management Practice Guide – Expert Reviewer
• IIBA Competency Model – Lead Author and Team Lead, V1, V2, and V3.

Rachael Wilterdink
Principal Consultant
Infotech Enterprises

Rachael Wilterdink is a Principal Consultant with Infotech Enterprises. With over 25 years of IT experience, she holds multiple business analysis and Agile certifications. As a consultant, Rachael has served clients in the financial, retail, manufacturing, healthcare, government, non-profit, and insurance industries. Giving back to the professional community, Ms. Wilterdink served on the boards of her local IIBA® and PMI® chapters. As a passionate public speaker, Rachael presents various topics at conferences and user groups across the country and the world. Rachael is also the author of the popular eBook "40 Agile Transformation Pain Points (and how to avoid or manage them)."

Bibliography

"2021 Business Agility Report: Rising to the Challenge." Business Agility, 2021. Accessed 13 June 2022.
Axure. "The Pitfalls of Agile and How We Got Here". Axure. Accessed 14 November 2022.
Beck, Kent, et al. "Manifesto for Agile Software Development." Agilemanifesto. 2001.
Brock, Jon, et al. "Large-Scale IT Projects: From Nightmare to Value Creation." BCG, 25 May 2015.
Bryar, Colin and Bill Carr. "Have We Taken Agile Too Far?" Harvard Business Review, 9 April 2021. Accessed 11 November, 2022.
Clarke, Thomas. "When Agile Isn't Responsive to Business Goals" RCG Global Services, Accessed 14 November 2022.
Digital.ai "The 15th State of Agile Report". Digital.ai. Accessed 21 November 2022.
Hackshall, Robin. "Product Backlog Refinement." Scrum Alliance. 9 Oct. 2014.
Hartman, Bob. "New to Agile? INVEST in good user stories." Agile For All.
IAG Consulting. "Business Analysis Benchmark: Full Report." IAG Consulting, 2009.
Karlsson, Johan. "Backlog Grooming: Must-Know Tips for High-Value Products." Perforce. 18 May 2018
KPMG. Agile Transformation (2019 Survey on Agility). KPMG. Accessed November 29.
Laguna, Fabricio "REQM guidance matrix: A framework to drive requirements management", Requirements Engineering Magazine. 12 September 2017. Accessed 10 November 2022.
Miller, G. J. (2013). Agile problems, challenges, & failures. Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.
Product Management: MoSCoW Prioritization." ProductPlan, n.d. Web.
Podeswa, Howard "The Business Case for Agile Business Analysis" Requirements Engineering Magazine. 21 February 2017. Accessed 7 November 2022.
PPM Express. "Why Projects Fail: Business Analysis is the Key". PPM Express. Accessed 16 November 2022.
Reifer, Donald J. "Quantitative Analysis of Agile Methods Study: Twelve Major Findings." InfoQ, 6 February, 2017.
Royce, Dr. Winston W. "Managing the Development of Large Software Systems." Scf.usc.edu. 1970. (royce1970.pdf (usc.edu))
Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Pearson Education. 2012.
Singer, Michael. "15+ Surprising Agile Statistics: Everything You Need To Know About Agile Management". Enterprise Apps Today. 22 August 2022.
The Standish Group. The Chaos Report, 2015. The Standish Group.

Where do I go next?

Improve Requirements Gathering

Back to basics: great products are built on great requirements.

Make the Case for Product Delivery

Align your organization on the practices to deliver what matters most.

Requirements for Small and Medium Enterprises

Right-size the guidelines of your requirements gathering process.

Implement Agile Practices that Work

Improve collaboration and transparency with the business to minimize project failure.

Create an Agile-Friendly Gating and Governance Model

Use Info-Tech's Agile Gating Framework as a guide to gating your Agile projects following a "trust but verify" approach.

Make Your IT Governance Adaptable

Governance isn't optional, so keep it simple and make it flexible.

Deliver on Your Digital Product Vision

Build a product vision your organization can take from strategy through execution.