Gathering Requirements in an Agile World

Many agencies have adopted Agile methodologies for their projects because it allows for more flexibility and rapid deployments compared with traditional monolithic approaches. Waterfall processes encourage the creation of lengthy documents detailing every technical aspect of the project prior to any work starting, whereas Agile encourages a more “on the fly” approach. However, one common pitfall under Agile is to ignore the importance of gathering useful and effective requirements. Within the Agile methodology, knowing when and how to gather requirements can be confusing, but having the following types of accurate and useful requirements at each stage of an Agile project is vital to success. 

Business/User Requirements 

The very first items that need to be discussed and documented are the business requirements for the project. This is the why of the project. These are the fundamental objectives that need to be met to ensure the project has succeeded and are an artifact of discussions between the client and Project Manager (PM). They should be very high level and reflect larger strategic objectives for the client. Also, they should take in account any technical, time, and budgetary constraints that may impact the scope of the project. The size of the project will dictate how lengthy the business requirements will be, but they generally range from a few sentences or bullet points up to a page or two in length. Some brief examples of effective business requirements: 

• “Better communicate our community building efforts to our readers” 
• “Reduce the frequency of items being abandoned in carts to increase sales volume.” 

Functional Ideation/Requirements 

After the business requirements have been gathered, the next step is to explore possible solutions to them and document the result. This is the “what” of the project. Ideating potential solutions should involve team members from as many different disciplines as possible to consider all the alternative approaches to meet the business requirements. This stage could potentially create a crude proof of concept or mockup to verify the solution is viable, but the most important artifact are the rules that dictate how the solution will look and work. Without getting into technical details, determine what needs to happen in order to satisfy the business requirements. These rules should detail the entire workflow including “error paths” that account for invalid data, dependency failures, API outages, etc.  

The PM should lead a meeting with representatives of back-end development, front-end development, design/user experience (UX), and quality control (QC) to develop a complete picture of the feature before sprint planning begins. For larger projects, this meeting may need to be repeated as the sprint retrospective cycle provides additional insight. It is vital that the functional requirements are accurate as they become the basis for work estimates and QC test scripts. Functional requirements would look like: 

• “The events module should automatically display the next 4 upcoming events.” 
• “An email should automatically be sent to users 4 hours after adding an item to their cart if it has not been subsequently removed or purchased.” 

 Implementation/Transition Requirements 

Once the functional requirements are complete, the final step is to detail how the solutions will satisfy the functional requirements, and thereby meet the business requirements. This is the “how” of the project. Despite the artifact of these requirements being technical in nature, to avoid later rework it is imperative to consider all aspects of the feature to gain holistic view and develop a complete solution. Be mindful of other features, the site editor experience, dependencies such as APIs and third-party libraries, how back-end and front-end code will be integrated, performance, security, etc. when writing the technical requirements. 

Again, the PM should lead meetings with the entire team to review the functional requirements and determine the best technical solutions – potentially prior to each sprint being planned. The feature should be broken down into smaller component tasks that can be completed in one day at this point. Anything larger must be further broken down in order to allow for the most accurate work estimation and burn-down reporting. These requirements will be used as the blueprint for each sprint, so it is vital that they are accurate, complete, and discrete. Based on the previous functional requirement examples, technical requirements would look like: 

• “Upon successful API retrieval of the JSON object, the event title, date, time, and location placeholders will be dynamically replaced via JavaScript” 
• “Removing an item from the cart or completing the checkout process will trigger an API call to HubSpot update the user workflow” 

Final Thoughts 

The ability to adapt to changes during a project is one of the major advantages of the Agile methodology, but this flexibility does not preclude long-term planning from remaining vitally important. It is the project manager’s duty to ensure that everyone takes the time to stop, gather useful requirements, and plan accordingly before diving into work. Agile provides many benefits, but it does not operate by magic. If it isn’t clear what is being done, why it is being done, and how it is being done, then it later cannot be possible to verify that the project was successful, that it was done correctly, or that it was done in an appropriate amount of time. Having solid requirements provides the framework that allows those questions to be answered.