5 Best Practices for Managing Requirements in Agile Projects

Success of agile project management greatly depends on the approach to requirements specification which includes several best practices. The agile approach promotes a highly iterative, collaborative environment in which the team, project manager and senior stakeholders enjoy flexibility in addressing any inherent risks associated with managing requirements. An interesting feature of this approach is that a change to project requirements can be turned into a competitive advantage later on, as compared to the traditional approach which doesn’t ensure adaptability to the changing environment. In this article, I write about 5 best practices for managing requirements in agile projects.

1) Review Requirements Collaboratively

Collaboration paves the way for better knowledge transfer and interactive data exchange. People working in collaboration with each other make a greater contribution to a common goal, rather than an individual trying to address the same goal personally.

Collaborative reviews determine best practices for managing requirements in agile projects. In its “pure sense”, reviewing of project requirements needs to be managed as an ongoing process of collaborative meetings, discussions and negotiations during which the team can analyze necessary information and communicate the context to the project manager and stakeholders, and vice versa. By verifying the software project requirements in collaboration, the manager can guide the team through further iterations and also agree with the stakeholders whether or not the project adds value to the business.

Typical Mistake

Although collaborative requirements management works excellent in any agile project environments, use of the right techniques determines whether the project will be communicated to the team the way that expresses the requirements best of all. A typical mistake here is that sometimes, even working collaboratively, agile teams try to collect and refine requirements right from stakeholders, rather than use the time-proven methods of elicitation, discovery and validation. Those teams tend to jump up to project execution too early, when in fact the planning stage doesn’t get finished. They really don’t understand the business needs to be addressed by the project and the value required by the stakeholders.

Negotiator

To avoid such a mistake and review and refine requirements at the planning stage, a team needs to collaborate with a negotiator who directly communicates with stakeholders. The role of negotiator can be taken by the project manager if it is admitted by the project organizational structure. However, ideally there should be an individual who could focus on the negotiations with the stakeholders and also could provide feedback from the team and project manager. For example, a business analyst can use collaboration techniques to help the stakeholders feel that their requirements are clearly understood by the team and that the project manager moves the team in the right direction. First, this person communicates with the stakeholders on the business value, then meets with the team and project manager to agree on the requirements, and finally works on improving the project in progress until the business value is delivered and the requirements are met.

2) Visualize Agile Project Requirements

Visualization makes it much easier and faster for people to understand information and put it in an appropriate context. Visuals, rather than text, accelerate an individual’s perception of the situation and help generate decisions faster and in right context. Meanwhile, visualization needs to be combined with text and audio; visuals without text/audio can be too ambiguous otherwise.

Mind Mapping Best Practices for Creating Visuals

Following best practices for managing requirements, I prefer using mind mapping software that enables better and faster recognition of information. By visualizing project requirements with help of mind mapping technique, I create and present a visual map to my team in meetings, and we discuss the business value required by the stakeholders. The mind map shows the concepts, their relationships and the desired outcomes as well. We also brainstorm the mind map and keep record of new ideas. The information captured in the meetings is documented and then shared with the stakeholders, they provide feedback that we discuss later on, and this cycle goes on until the requirements are best framed and refined in the right context. Till this moment, the visual map can be updated and modified many times.

3) Analyze Current State and Understand Future Gaps

There is a common mistake in agile projects that is too much attention is paid to how the development process is getting changed, but possible difficulties and gaps in the future are ignored or left unhandled unless the troubles come up suddenly. Teams spend too much time and effort on documenting and analyzing current state. Even their project documents, visuals and mind maps remain greatly about the things happing right now, and not about the future. I’m not trying to say that a work-in-progress analysis should be ignored, because such an analysis is really needed for the project manager and team to understand the current gaps. What I’m trying to advocate is, the project manager should analyze the risks and issues in ongoing software dev tasks, figure out a plan of action for future, and lead the team through the plan to get to the future desired state.

Managing Requirements

First, all of the context, visuals and other best practices of requirements management the agile team uses in software development need to be carefully reviewed by the project manager, business analyst and stakeholders. On the one hand, these tools should represent the current state of the dev process and explore the issues the team is facing. On the other hand, the project manager in collaboration with the business analyst and stakeholders should agree on the solution for future troubles and on the desired state of the project. And the requirements would be the key to linking the current state and the future desired state. Best practices for managing requirements in agile projects would help answer the questions, “Why are we spending our resources on changing the current state?”, “What future gaps do we want to solve?”, “What value will the solution deliver?”

4) Manage Requirements with Change Requests

Agile project management is highly adaptive to user requirements and makes a software development environment match changes. Traditional PM appears to be less flexible in this context; however it ensures greater predictability and steadiness of the development process from the very beginning of the project. Nevertheless, both styles of PM assume use of change requests that enable correction and verification of project requirements.

Requirements Allocated Too Early

Sometimes, in software development projects, requirements are allocated to the development process too early, and so the team begins to develop an application that doesn’t match the user needs partially or entirely. The problem is that the requirements are not corrected and verified throughout the process, because change requests are not considered as expected. Moreover, it happens that because of poor communication and collaboration the dev team receives a notification that the product requirements need to be changed but it’s not clear how exactly. The team gets stuck and waits for clarification, which involves waste of time.

Negotiations Break the Ice

The solution is again in close collaboration, and negotiations will be the key. A business analyst needs to keep track of all requests initiated by the stakeholders (customer or user), communicate with the project manager on the required changes, and oversee how the team implements the changes in the product. Close collaboration between project participants multiplied by productive negotiations will break the ice and remove interruptions in the development process.

5) Keep Requirements Documentation Organized

Many organizations that run app development and agile projects often keep their requirements documentation unorganized, so the essence of what requirements state is missed. The mistake I see is that project documents keep the details on tasks, detailed technical design, and business rules, while they say little about the context and capabilities needed. Unorganized or missed information on business and solution requirements sets the project up for missed value and opportunity to the stakeholders. Meanwhile, keeping and organizing records on the true requirements will shorten the project timeline and prevent many troubles in the agile design process.

Best Practices

Here are some considerations that keep requirements documentation organized:

• Project tasks and design need to be  differentiated from requirements spec
• Understand and analyze project capabilities needed to implement the tasks and design
• Keep the team focused on the true requirements through the software development process
• Project plan must account for feasibility and alternatives
• Manage requirements change soonest upon request
• All project documents need to be updated progressively as requirements are discovered and changed.