Get certified - Transform your world of work today


Agile Projects Requirements Management

The 12 Checkpoints Approach

6 August 2015

Vikash Karuna
Hexaware Technologies Ltd.

One of the inherent characteristics of Agile software development is to welcome changing requirements and accept the fact that the project's requirements will evolve as development progresses. Unlike the Waterfall model, having complete, stable, and well-documented requirements are not the prerequisites to start Agile project development. Therefore, they're needed only to address the changing or evolving business requirements effectively during the Agile software development life cycle. With this requirements management approach, we want to establish best practices for the following categories of requirements:
  • Known requirements: Stated known features, functionalities, and nonrequirements that were identified during the product envisioning stage
  • Evolving requirements: An evolutionary software development approach in which product features and functions are inherently evolutionary in nature and requirements grow based on market conditions, product demand, evolution of users' needs, product feature aging, etc.
  • Changed requirements: Product features and functions that were based on assumptions, poorly defined, ignored, or missed due to lack of visibility and knowledge; or human errors during the initial requirement exploration and product envisioning
We define system functional requirements as system behavior or functions comprised of business rules, administrative and transactional functions, authentication and authorization, audit tracking, reporting, statutory compliance, audits, and certification requirements.

The nonrequirements are all nonfunctional requirements (NFRs) that are mostly viewed as system-operation or quality attributes rather than system behavior or functional aspects. Depending on the system definition and context, some of these nonrequirements may become system requirements categorically embodied as product features and evolve or change over the product development life cycle.

How to handle requirements effectively

Following are key focus areas and checkpoints that help us ensure that requirements are managed effectively.

1. Assign dedicated product owners to the project.
Designate a dedicated product owner to the product, one who has a complete business understanding of product features and has knowledge of the functional domain and the solution being developed. This ensures consistent and high-level customer participation throughout the software development process.

A designated product owner should be well versed in Agile/Scrum and should fully understand the roles and responsibilities of a Scrum product owner. The product owner not only participates in the development of requirements but also writes, prioritizes, and defines the acceptance criteria for the requirements. Throughout the development process, he or she should resolve any requirement ambiguities and functional queries from the development team. From the customer's perspective, the product owner is the team's face. Depending on the team size and the product functions' size and number, it's a best practice to have multiple product owners per product group who each own specific product modules (epics) or related product features (themes).

2. Assign on-premise product owners or proxy product owners, as required.
Try to have on-premise, colocated product owners for the entire project duration. But in a distributed development environment (mostly in an onshore-offshore model), in which the project team works at multiple locations and in multiple time zones, this is often unlikely. In some cases, the customer appoints a product owner from the business users' group who doesn't understand Agile practices fully and is unable to participate and allocate dedicated time to the project. For this reason, the development team might not execute the project effectively. To overcome these challenges, have proxy product owners for each Scrum team who can represent the business team in the event that the product owner is unavailable.

Ideally, the proxy product owners should have a business analyst's background, with approximately the same level of expertise and business understanding as that of a product owner. They should work in close collaboration with product owners to facilitate decision making, resolution of developers' queries, and timely availability of the required information. They can also contribute to backlog refinement, participate in sprint ceremonies, and perform all activities and responsibilities of a product owner whenever required.

3. Create a high-level product requirements backlog during the initial sprint.
Create a high-level product backlog during the initial sprints (or iterations) that is a list of all product features arranged as epics, themes, and user stories (if possible). The initial set of product features should be prioritized based on business values and market availability; it is also used in planning potential releases to market or the business community. Identifying the initial high-level requirements early in the project helps the team to understand the scope of work that must be completed for timely delivery of the product.

4. Continually refine the product backlog.
The product owner should prioritize undelivered product features regularly based on factors such as business value, business risk, and early time to market. The development team selects backlog items in the same priority order for refinement, elaboration, and estimation, along with acceptance criteria. This selection allows them to meet the Definition of Ready (agreed requirement readiness checkpoint) prior to including the items in the sprint backlog for future development in a given sprint or iteration. The product owner owns and maintains the product backlog.

5. Actively involve the development team during the product backlog refinement.
Product backlog refinement should be the joint responsibilities of the product owner and the development team (including the ScrumMaster). During the backlog refinement meeting, the product owner presents the list of priority work items. The team participates by understanding, asking for clarifications, elaborating, and estimating.

The expectation is that a sufficient number of backlog items are presented for consideration and are fine grained, with a consumable level of detail. The product owner may define the initial set of acceptance criteria for the work items, but it's the development team that should define a detailed level of acceptance criteria for each work item. This provides opportunities to further split the larger work items into smaller ones for better control in driving them to completion (meeting the Definition of Done).

The product owner is responsible for elaborating on any poorly defined backlog items or items with associated risks of unknowns. The development team must fully understand the backlog items to select potential candidates as sprint backlog items. This understanding is also the basis of streamlining the sprint planning meetings.

6. Include changed requirements or enhancements to released features.
In each sprint or iteration, the development team implements (develops, tests, and releases) sprint backlog features by picking up high-priority and high-risk items early. Sprint backlog items are always a subset of the product backlog selected according to the priority list.

The product owner updates the product backlog with any changed requirements or enhancements by priority and severity so that they can be considered for development later. Only the product owner has the complete authority and responsibility to maintain the backlog by adding new requirements, changing existing requirements, removing invalid requirements or those that are no longer necessary, and reprioritizing them as required. The sprint backlog limits the work-in-progress items and at the same time helps with the progressive elaboration and management of requirements. Therefore, any additions or changes to the sprint backlog should be avoided.

7. Control and guard the sprint backlogs.
Include any new user stories or changes to any existing user stories in the product backlog instead of the sprint backlog. The sprint backlog should only consist of work items committed by the team, and its completion becomes the team's short-term goal. At any point in a sprint, the overall work-in-progress items should be kept to a minimum. Team members pick up the top-priority and high-risk items for development first. If for any reason there is a change in the sprint backlog requirements (and thereby a change in the work-in-progress items) within the current sprint, choose one of the following options:
  • Include the changes or new requirements in the current sprint.
  • Include the changes or new requirements in a subsequent sprint.
  • Abandon the current sprint and start a fresh sprint to address the changed or new requirements.
You can choose any one of these possible actions based on one or more of the following factors:
  • Whether the work on the changed user story has already started
  • What the overall impact of changes is on the existing work items (user stories)
  • What the stage of the current sprint is; whether the change was discovered early or late in the sprint
  • Whether the changed user stories can be pushed to subsequent sprints to clear some technical debt
Estimate the changes to work items and analyze the overall impact on existing work items. If the team concludes that changes can be incorporated within the same sprint, then this effort should be considered. If the changes impact negatively or deviate greatly from the initial intended outcome, then it makes sense to either take the change within the same sprint or push that work item to a subsequent sprint. In any case, make an adjustment to the current sprint backlog so that the overall efforts and duration do not change. This could be handled by removing the relatively lower-priority and unstated work items from the current sprint backlog, keeping the total effort the same.

If none of the sprint backlog items can be removed, and incorporating changes has high impact on the overall sprint duration and team capacity to address it within the same sprint, then that work item should be pushed to subsequent sprints if the work has not started. If work has already started, the changed items are a priority, and they cannot be pushed to a subsequent sprint, then it makes sense to abandon or kill the entire sprint, and start a fresh one. When it's obvious that work being done is wrong or incomplete and it will become obsolete, or that it will have less value than what it's worth, discontinue work right away and focus on the new and important priorities.

It's worth noting that abandoning a sprint should be the last option, and, if required, may be considered early in long-running sprints. Abandoning a sprint should not be the obvious choice because there is a loss to the work done and an abandoned sprint isn't normally followed by a retrospective meeting. Rather, a fresh sprint starts with the appropriate sprint planning meeting. Abandoned sprints are normally considered failed sprints and therefore should not impact the team's velocity or any related project metrics. Ideally, such a scenario should not exist, and the product owner should ensure that such incidents do not occur. The product owner should work closely with development and the business team beforehand to proactively analyze, prioritize, and plan backlog items effectively, especially for work items that are planned for the upcoming sprint backlog.

8. Encourage customer or user participation for reviews and feedback.
Participation of a customer business team (or end users) who will actually be using the product is essential to improving software quality, user satisfaction, and system acceptance.

It's important to plan for the business users' participation in the software development process by using the appropriate communication mechanism to solicit feedback at regular intervals (releases). Users well know the business domain and the intent and condition for which the product should function to address the business problems. Therefore, business users should be an integral part of the software development process to obtain their feedback. This can be achieved by ensuring that a product with potential, shippable features is released for testing, and by ensuring their commitment to testing and providing reviews and constructive feedbacks for improvements.

9. Shorten the sprint duration.
Preferably the sprint should last one to three weeks instead of four or more weeks. Having a shorter sprint duration has comparatively more advantages, as it provides frequent iteration and course correction opportunities for the following reasons:
  • More frequent releases: Feedbacks are obtained comparatively earlier, and the customer review and feedback loop becomes more frequent. There's more opportunity to engage customers and other stakeholders during the sprint ceremonies, which gives opportunities to identify any requirement changes earlier in the product development life cycle.
  • More frequent and shorter sprints: There is more room to incorporate changed or reprioritized work items. The likelihood of abandoning sprints becomes less due to shorter sprint durations. The opportunity to push changed work items to subsequent sprints increases without the impact of not accommodating the changes within the current sprint.
  • More opportunities for continuous improvement, course correction, and higher project visibility: Retrospective meetings can be held at shorter intervals frequently, which gives more opportunity to review the work, process lessons learned, and take action for improvement.
10. Handle nonrequirements effectively.
Set nonrequirements for all work that has been categorically stated by business (or by the product owner on behalf of business) as requirements that need to be considered for development. Such requirements could be either technical or nontechnical in nature. System requirements, such as performance, security, usability, interfaces or dependencies, availability, scalability, maintainability, extensibility, testability, portability, reusability, compatibility, and recovery time or fault-tolerance, fall under nonrequirements. There could be functional or nonfunctional known issues, technical debts, or testing defects/issues found in previous sprints or iterations.

All such nonrequirement work items should be discussed, negotiated, and agreed upon with the product owner or responsible stakeholders prior to consideration. Such nonrequirements could be considered for implementation with the appropriate level of planning in a sprint or in the slack time of a sprint schedule, as required.

11. Set up disciplined communication with customer and stakeholders.
Following Agile software development processes does not mean making any requirement changes or additions without conducting the appropriate level of impact analysis and subsequently communicating any repercussions to the customer. The project team should set up a process to handle the requirement changes or additions appropriately.

They must analyze and communicate the impact on efforts, cost, or schedule to the project stakeholders and customer. Undertake and negotiate with the customer or stakeholders the effort and cost estimations, including the feasibility study, to determine the probability of meeting the predefined timeline and budget. If required, historical data on change management can be used to substantiate and validate the assumptions.

12. Provide for a contingency buffer to project cost and schedule.
While planning for iterations or releases, it makes sense to consider some contingency buffers to accommodate some anticipated or surprise changes on the requirements front. Without such buffers, any rework or extra work can lead to a schedule slippage and an additional cost, so it should be factored proactively as deemed necessary.


The Agile software development process has originated and evolved to address the industry's problems caused by changes in requirements. The industry has recognized, acknowledged, and accepted this reality. With the appropriate level of control and process alignment, evolving or changed requirements can be effectively addressed and managed to the satisfaction of project stakeholders.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.5 (15 ratings)


Kaushik Saha, CSP,CSM,CSPO, 8/10/2015 1:40:31 PM
Nice Article Vikash..very much self-explanatory.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up