Skip to main content

Author: Stephanie Vineyard

What Is the Lifecycle of a Requirement?

In a traditional IT environment, requirements are created at the beginning, handed down the process, and validated at the end. In an Agile IT environment, requirements represent working software and are created, refined, and revised in a circular process.

So, what does that requirement lifecycle look like in an Agile environment?

Related Article: User Stories & Mousetraps: A Lifecycle of Conversations


1) Build the Right Thing

The first step is to identify why we are doing something. Stakeholders come to us with their identified problems. However, it is up to the business analyst to probe for the root cause, the business value desired, and the innovative solution.

For example, a homeowner requests new hardwood floors so they look like the day the house was new. We need to know if the customer wants new floors for $12,000 or to refinish the existing floors at $4,000.

Second, we determine who is using our product. We want to know who is our audience, what matters to them, and how we get their feedback. We can use techniques such as story mapping.

Third, turn key features into requirements that deliver customer value. Once we understand the Why and the Who, we align our feature requirements based on the value it delivers. In this way, we ensure all feature development delivers value, and we reduce the likelihood of waste.

2) Build the Thing Right

Once we’ve determined the right thing, we begin the process of building the thing right. The requirement lifecycle continues to get as independent, small, and testable as possible. This example demonstrates the refinement process.

Vertically slice your requirements to create stand alone, customer-value-driven requirements – not architecture-oriented, stack-oriented, or data-oriented.
  Start: I need a form which collects the number of family members for one unit.
I need to calculate the total number of family members based on number of adults and dependents.
Progressively elaborate further using INVEST   New:
I need to collect the number of adults within a family.
I need to collect the number of dependents within a family.
Break down these requirements into user stories.   For total number of adults:
As a client manager, I want to sum the number of adults based on date of birth in a family so that I can report accurate information to funding organizations.
Add objective, measurable, testable acceptance criteria to measure when the criteria is satisfied.   Acceptance Criteria:
– Must be a whole, positive number
– Must be larger than zero

3) Gather feedback

The lifecycle leads you through the process back to the beginning. You need to collect customer feedback once you’ve implemented an independent, small, testable feature.

At this stage, measure how your customers or clients use the features. Compare results with your goals and objectives identified in your Product Vision. Revisit “Build the Right Thing”. Did you get it right? What do you need to change? What do you need to add?

Why Does my Development Project Need a Business Analyst?

The short answer: Because you want a project delivered on time, meets your specifications, and works for the end customers.

The long answer: The following project is a real example to illustrate the missing pieces and how a business analyst could have made a huge impact. Do you see similarities with a project you have?


A team member (let’s call him Guy) worked with the client managing multiple Excel spreadsheets. Guy saw a pain point and realized he could do something about it. He suggested building a web application with relational databases to help the team. The client liked this idea because they realized this new tool would impact forecasting and reporting – affecting the bottom line.

Guy set to work with the client outlining the project and developing the tool. A talented project manager (Pam) joined the project. Despite Guy’s knowledge of the business process and technical skills and Pam’s attention to detail, this product was behind schedule. The end customers found that this tool relieved some pain points but didn’t address all of their needs or use cases.

What happened?

Why did a product that started out so promising end behind schedule and not fully addressing the end customers’ need?
Simply put, because there was no business analyst. Guy spent his time working with the client to understand the use cases instead of developing the tool. Pam spent the majority of her time collecting the requirements from the client. No one talked to the end customers. The only requirements provided where the “Shalls” included in the contract that did not cover the full scope of the tool. And most importantly, no one ensured Guy spent his time developing instead of gathering user stories.

What does a business analyst provide?

The most important value a business analyst provides is getting the right information to the software developer in the right manner. The business analyst works with the team to make sure the product delivered fits their needs. In this case, a business analyst allows the developer to focus on developing code.

Business analysts bring:
• An understanding of the business needs and the client needs
• A full understanding of user stories and use cases for the end customer
• Detailed requirements translating the customer needs into technical tasks
• Clear communication with the developer to create the right tool
• Detailed work with the project manager to confirm deliverables are on time and meet the contractual obligations

Wrap up

So why should I spend extra money for a business analyst? Because omitting this crucial team player will cost me in time and quality of the final product.

Do you have an example of a project that succeeded because of a business analyst’s work? Do you have a project that could have been better with the help of a business analyst?

Want a Successful Agile Team? Include a BA!

My client’s project struggled for direction. The team spent 4 months trying to determine what to build. Then, most of the team quit. A new team formed with the imperative to “just get something in the hands of the end user.” The team achieved this in 2 months, but now they realize the value, purpose, and priorities of the project are unknown. In discussing next steps, the Development Lead Manager asks:

“Why would we need a business analyst? Can’t the developers just talk with the end user? Isn’t the problem the users don’t know what they want?”

Agile teams often overlook the role of business analysis or assume the Product Owner fulfills this role. Show me a team struggling with quality, product reworks, and delivering value, and I’ll show you a team with no business analyst.

Successful BAs Help With Communication

The biggest benefit provided by a business analyst (BA) is communication. Expressed as an Agile value, business analysts help with customer collaboration over contract negotiation.

Business owners and developers speak different languages. In many cases the developer has a natural tendency to think they know how to build a solution without the need for clarification. The business owner struggles to express needs in terms of priority and treats every idea or suggestion as equally important. The result of this is an incomplete solution and an unhappy customer.

Having someone there to get everyone on the same page and agree is critical. The business analyst is an honest broker for building the right solution, defining the acceptance criteria, and seeking clarification when needed. The business analyst is constantly facilitating discussion, documenting requirements, and testing and validating the solution.

The goal of Agile software development is working software over comprehensive documentation. A common conclusion is that developers matter and non-developers are unnecessary.

When a software product team is successful, the developers and designers (those making the tangible product) get all the credit. When the product team does not succeed, the blame is on ill-defined requirements, poor testing, or lack of management.

As a result, management tends to overlook the BA role when forming a team. Since the work of the business analyst on the Agile team is non-tangible, it is easily forgotten. This is like building the next best search engine but omitting the server capacity necessary to handle the traffic load – a disaster waiting to be discovered.

BAs and the High Performing Team

So what does a high performing team with business analysts look like? It is a team which responds to change quickly and easily over following a plan. What leads a team to success is really about preparation: determining the value, purpose, and priority before investing time and money.

The business analyst brings preparation and planning to get stakeholders’ perspective. These advance conversations discover those insights in advance, so the approach is from a value-first, holistic solution rather than functional perspective.

The high performing team also gets feedback early and often. The business analyst will solicit and facilitate this feedback throughout the process, even more often than just at sprint reviews. Getting the feedback sooner means the team doesn’t make mid-stream course corrections or deliver an unsatisfactory solution.

In the end, it is about individuals and interactions over processes and tools. There is no single correct answer for implementing Agile principles and values on a team. In the same fashion, there is no single correct answer for how a business analyst works with an Agile team. If there is a project with many repeatable steps and few unknowns, a BA is not necessary. But when the team relies on stakeholder input, the product is new or a significant change, or your Product Owner struggles to break down features to stories, the team needs a business analyst or team of BAs to succeed.

Don’t forget to leave your comments below.