BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

This content is part of the Essential Guide: Gathering and managing software project requirements
Q
Manage Learn to apply best practices and optimize your operations.

How Agile teams manage continuous requirements

Find out why continuous requirements are common for Agile teams and are necessary for continuous development flexibility.

How does requirements gathering change when development is continuous?

For Agile teams, continuous requirements gathering will be very familiar. The changes an Agile team will likely make as it transitions to continuous delivery or continuous development are in many ways more of the same: iterations become shorter, the scope of each project decreases, and requirements grow more flexible.

The difference in continuous development is that communication, modeling and design discussions occur continuously and not only in scheduled meetings. Teams don't need to sit in a circle, holding hands and singing "Kumbaya." But they must be comfortable asking questions, bringing up ideas and discussing them in the group -- repeatedly, if necessary. Talking among the team is important. It doesn't matter if it happens in person or via IM, email or teleconferencing. What's important is that it happens.

Many teams use a white board to draw out design ideas; while others may use modeling or flowchart techniques, depending on the size and complexity of the change or its implications to other parts of an existing application. The important part is that the team decides on the mode of communication they implement best. The right tool is the one that works best for that particular mix of people.

It is also essential to an Agile team's success that requirements be documented. They can be part of a user story or any other type of document. The purpose is to save ideas and track what the code does, continuously. Team members change and business priorities change, so it's imperative that design decisions are documented continuously, as well.

Generally, complex changes should be broken down into smaller pieces. Smaller pieces are easier to manage, and that's the secret to continuous success. Continuous development doesn't remove the responsibility of defining requirements, but it requires they be gathered continuously as features are designed.

Dig Deeper on Software Requirements Gathering Techniques

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

TheServerSide.com

SearchAWS

SearchBusinessAnalytics

SearchHRSoftware

SearchHealthIT

Close