One of the inherent characteristics of the Agile Software Development is to welcome changing requirements and accept the fact that project’s requirements will evolve as development progress. Unlike the waterfall model, having complete, stable and well-documented requirements are not the pre-requisites to start the Agile project development. Therefore, it’s needed to effectively address the changing or evolving requirements during the software development life-cycle. With the below mentioned requirement management approach, we want to establish best practices for the following categories of requirements:
Known Requirements: Stated known features, functionalities and non-requirements 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 to 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 etc.
The non-requirements are all non-functional 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 non-requirements may become system requirements categorically embodied as product features and evolve or change over the product development life.
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 Owner(s) to the Project.
Designate a dedicated Product Owner to the product being developed, 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 with the Agile/Scrum and should fully understand the roles and responsibilities of the Scrum Product Owner. The Product Owner not only participates in development of the 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 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, it’s the 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 Owner or Proxy Product Owners, as required.
Try to have on-premise, collocated 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 multi-locations and in multiple time zones, this is often unlikely. In some cases, the customer appoints a Product Owner from 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 Product Owner. They should work in close collaboration with Product Owner to facilitate speedy decision making, resolution to developer’s 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 initial Sprint.
Create a high-level product backlog during initial sprints (or iterations) that is a list of all product features arranged in the form of 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 business community. Identifying the initial high-level requirements early in project helps the team to understand the high level scope of work that need to be completed for timely delivery of the product.
4. Continuously refine the Product Backlog.
The Product Owner should prioritize the 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. The selected backlog items should meet the Definition of Ready (agreed requirement reediness 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 Product Owner and development team (including Scrum Master). Team should actively participate and contribute to the backlog refinement process in close collaboration with the Product Owner. During the backlog refinement meeting, the Product Owner presents the list of priority work-items. The team participate in understanding, asking clarifications, elaboration and estimation.
The expectation is that a sufficient number of backlog items are presented for consideration and should be fine-grained with consumable level of details. The Product Owner may define initial set of acceptance criteria for the work-items but it’s the development team that should define a detailed level of acceptance criterion 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 to defining of done).
The Product Owner is responsible for elaborating 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 effectively.
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 Product Backlog selected according to priority list.
The Product Owner updates the Product Backlog with any changed requirement or enhancements by priority and severity so that they can be considered for development later. Only the Product Owner should have the complete authority and responsibility to maintain the backlog by adding new requirements, changing existing requirements, remove invalid requirements or those that are no longer necessary, and reprioritizing them as required. Sprint backlog limits the work-in-progress items, and as per the capacity, team commits to progressively elaborate and implement these items. Therefore, any additions or changes to the sprint backlog should be avoided.
Agile Requirement Management
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 member pick up the top-priority and high-risk items for development first. If for any reason there is change in the sprint backlog requirements (and thereby change in the work-in-progress items) within the current sprint, you can choose one of the following options:
Include the changes or new requirement in the current sprint.
Include the changes or new requirement in a subsequent sprint.
Abandon the current sprint and start fresh sprint to address the changed or new requirements.
The selection of any one of the above mentioned possible actions will depend on one or more of the following factors:
Whether the work on the changed user-story has already started or not
What is the overall impacts of changes on the existing work-items (user-stories)
What is current stage of the current sprint, whether change discovered early or late in the sprint
Whether the changed user stories can be pushed to subsequent sprints and clear some technical debts instead
Estimate the changes to work items and analyze the overall impact on the existing work items. Team can the appropriate action on changed work items as explained below –
If the team concludes that the change can be incorporated within the same sprint with little or no much impact, then this change should be considered.
If the changes impact negatively or deviates greatly from the initial intended outcome, then it make sense to either take that change within the same sprint or push that work item to 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 work item that is not started from the current sprint backlog, keeping the total effort the same.
If none of the sprint backlog item cans be removed, and incorporating changes has high impact on the overall sprint duration and team capacity to address that within the same sprint, then that work item should be pushed to subsequent sprints if the work has not started.
But if work has already started, and the changed item is of high priority, and it cannot be pushed to subsequent sprint, then it make 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 will become obsolete, or that it will have less values than it’s worth to discontinue work right away and focus on 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 is not normally followed by a retrospective meeting. Rather, a fresh sprint starts with the appropriate level of sprint planning meeting. Abandoned sprint are normally considered as failed sprints and therefore should not impact the team’s velocity or any related project metrics. Ideally, such 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 users participation for reviews and feedback.
Participation of a customer business team (or end-users) who will actually be using the product is essential to improve the software quality, user satisfaction and system acceptance.
It’s important to plan for business users’ participation in the software development process by using appropriate communication mechanism to solicit feedback at regular interval (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 the 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 on 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 corporately earlier, and the customer review and feedback loop becomes more frequent. There is more opportunities to engage customers and other stakeholders during 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 as 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 to 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 lesson learned, and take actions for improvement.
10. Handle non-requirements effectively.
Non-requirements could be set of all works that have 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 non-technical 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 non-requirements. There could be functional or non-functional known issues, technical debts or testing defects/issues found in previous sprints / iterations.
All such non-requirement work items should be discussed, negotiated and agreed with the Product Owner or responsible stakeholders prior to consideration. Such non-requirements 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. Setup disciplined communication with customer and stakeholders.
Following Agile software development processes does not mean making any requirement changes or additions that may be coming at any time, without conducting the appropriate level of impact analysis and subsequently communicating any repercussions to the customer and other stakeholders. The project team should setup a process to handle to requirement changes or additions appropriately.
Team must analyze and communicate the impact on efforts, cost, or schedule to project stakeholders and customer. Perform effort and cost estimation along with feasibility study to determine the probability of meeting the predefined timeline and budget, accordingly negotiate with to customer or stakeholders. If required, the historical data on change management can be used to substantiate and validate the assumptions.
12. Provision for a contingency buffer to project cost and schedule.
While planning for iterations or releases, it make 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 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 problem 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.