Some project teams believe agile means skimping on requirements management. They're dead wrong.
ISTOCKPHOTO
When they disregard this crucial component, they put project success on the line: For 35 percent of failed projects, a primary cause was inaccurate requirements gathering, according to PMI's 2018 Pulse of the Profession® report.
“Requirements management is at the heart of any project, agile or not,” says Thomas Zimmermann, PMI-ACP, PMP, global project portfolio manager for medical device company Karl Storz SE & Co. KG, Tuttlingen, Germany. “But in today's dynamic project life cycle, requirements are rarely frozen or fixed before development can start. Agile requirements management is necessary to cope with that.”
—Thomas Zimmermann, PMI-ACP, PMP, Karl Storz SE & Co. KG, Tuttlingen, Germany
Whether you're using Kanban, scrum, lean or any other type of agile approach, here's how to make requirements management a priority—and drive home project success.
REEL IN THE SKEPTICS
Team members who typically use agile approaches might see requirements management as unnecessary paperwork at best, a waste of time at worst. Jennifer MacNeil, PMI-ACP, PMP, breaks down that resistance with a simple question: “How can you test if you don't have written requirements?” says Ms. MacNeil, manager, Naval Nuclear Laboratory, Monroeville, Pennsylvania, USA.
In other words, how can team members testing a new app, for instance, know what to test for if there aren't established requirements for what the app is supposed to do? Even the most begrudging resister typically will concede that mapping out some requirements is a necessary start.
Another tack is to put requirements management front and center during demonstration sprints, says Noha Shaban, PMI-ACP, PMP, owner of Value Driven Project Consultancy, Melbourne, Australia. On a AU$5 million, 16-month project to build a customer relationship management system for a university unfamiliar with agile, Ms. Shaban managed two demo sprints with workshops that gathered requirements and then translated them into user stories. Her team worked with the product owner to reprioritize the user stories for the second sprint, and the product owner explained the process to other university stakeholders. “The university got to see how user stories are written and got to validate them against their requirements,” she says. With its client onboard, the team launched the project in earnest.
UNDERSCORE THE VALUE
“Agile doesn't mean not having requirements but making sure the requirements you work on in short periods of time deliver value,” says Maria Virtudes Briz, PMI-ACP, senior agile tecÚology project manager for the telecommunications company Telefónica, Santiago, Chile.
—Maria Virtudes Briz, PMI-ACP, Telefónica, Santiago, Chile
To do that, agile builds a shared understanding of the customer's needs among the owner, project manager and development team. “Requirements management becomes more about achieving what the business wants, rather than achieving what was planned,” Ms. Shaban says.
After each two- or three-week sprint, Ms. Briz's teams demonstrate their under-development product to the client, who then weighs in at each iteration. “You provide an incremental value, and you make sure you're working in the right direction,” Ms. Briz says.
Ms. MacNeil's agile projects focus on “what we absolutely must have for the project to serve the business,” she says. An agile approach to gather requirements “helps cut down all the extra requirements that aren't where the business value lies anyway.”
On an IT project to improve a client's business process, Ms. MacNeil's team treated the requirements gathering process as its own iterative project. The team conducted six sprints across six months just to gather the requirements. “With each sprint, our business partners saw more value as they saw the requirements developed over time, rather than waiting for six months to get a 100-page requirements document.” Iterative requirements management helps teams avoid ending up with a gap between the client's expectations and the end product.
MASTER THE ROLE
When teams take an agile approach, a project manager isn't tasked with gathering all the requirements at the start and then ensuring each one gets checked off during execution. Rather than acting as the requirements police, the project manager, serving as the team's scrum master, mitigates and removes any challenges that arise, says Ms. Shaban. That distinction is important to keep in mind if requirements management is a weak spot.
Tool Time
Source: State of Agile Report, VersionOne, 2018
For instance, the project manager must step in to clear blockages, such as delays, competing requirements, differences of opinion between the product owner and the business, or requirements that were supposed to get addressed in a particular sprint but didn't. The project manager communicates the problems to the product owner, who then decides to reprioritize or deprioritize certain requirements accordingly. “Requirements management isn't about maintaining control,” Ms. Shaban says. “It's about achieving a benefit.”
—Noha Shaban, PMI-ACP, PMP, Value Driven Project Consultancy, Melbourne, Australia
TELL THE STORY WELL
In agile, the team's shared understanding of the project's vision and evolving requirements is created through user stories: clearly written narratives that together make up the product backlog. The teams typically create a wireframe, or simple diagrams illustrating a basic user interface mock-up or prototype, says Ms. Shaban. Then, with each sprint, the product owner refines and reprioritizes the user stories, or requirements, as the project team estimates the time that each requirement needs.
It's up to the project manager to ensure those stories are told well—or risk losing the plot. While project managers on agile teams serve as conductors of information (What do users want from the product? What benefits will this feature provide?), they also have to don an editor's cap. They make sure the user stories are well-written with simple language and easy-to-follow acceptance criteria so that any team member can quickly understand them. “A secret to using agile is making sure the user stories are clear,” Ms. Briz says. Too much—or muddled—information is nearly as dangerous as too little.
At each sprint, the product owners collaborate with the development team to refine the backlog— reprioritizing some requirements, deprioritizing others. “As the project manager, you work closely with the business to prioritize the requirements for each sprint depending on the development hours you have. So you focus on value,” Ms. MacNeil says.
—Jennifer MacNeil, PMI-ACP, PMP, Naval Nuclear Laboratory, Monroeville, Pennsylvania, USA
Ms. Briz's teams also use the INVEST technique. They make sure each story is independent (of other requirements), negotiable (or open to discussion), valuable, estimable, small (or achievable with any one iteration) and testable. An independent user story doesn't depend on the completion of another, which could result in a bottleneck, while testing helps prove the product works and has value.
Ms. Briz saw the benefit of prioritization on a four-year project, completed this year, to deliver a water-efficiency system. It captures data from internet of things services such as soil-humidity sensors and then provides recommendations for how much water to use and when. When the team tested the sensors in a laboratory during an early sprint, they worked well and the customer approved them. But when the team conducted a trial in the field in a later sprint, unexpected environmental conditions, such as greater sunlight than anticipated, affected the sensors' performance. So the team added new user stories to the backlog that indicated the need to adjust the sensors so they could work under the actual light conditions.
Stakeholders thus benefit from a fast feedback loop. Rather than holding lessons learned sessions at the end of the project, at which point it may be too late or too costly to make corrections, agile teams can update requirements after each sprint.
“With agile, when we fail, we fail fast, so it's easy to make corrections,” Ms. Briz says. PM
