Keith Johnson is vice president of product development at Jama Software in this Sticky ToolLook interview, he discusses some of the changes that agile development has brought to the requirements management process.

Sticky ToolLook: In what we now consider “traditional” methodologies, a lot of effort is put into gathering the majority of the requirements up front. How does the requirements-gathering process differ in agile?

Keith Johnson: In traditional methodologies, time is spent working with the customer gathering details of the requirements and documenting all of them in detail prior to beginning any development. In an agile process, the requirements are identified at a high level, but details are not worked out with the customer until development begins. Prior to sprint planning, use cases are identified by the customer. As development begins, use cases are prioritized and implemented in two-week sprints. The customer and developer communicate to detail the use cases as they work on those cases. In traditional methodologies, the customer provides requirements and won't have further input until they are provided a release of the functionality. Agile allows the customer to be involved throughout the process and provide additional details or course correct as development progresses.

Sticky ToolLook: How does the different approach to requirements in agile organizations affect the rest of the agile development process?

Keith Johnson: By allowing the developer to have access to the customer, the developer is able to ask questions that may not be considered at the beginning of the project. It also allows the customer to understand how their requirements are being implemented so he or she can make improvements or think of additional requirements as the project continues. The overall effect is a higher-quality product that comes closer to meeting the customer's true business need. It also avoids surprises at the end of the project.

Sticky ToolLook: What’s the best way to keep requirements clear and consistent across teams in an agile organization?

Keith Johnson: As the development team works with the customer and additional details to the requirements are discovered, it's important to have a process to document the requirements as details are added. It's also important to track decisions being made along the way so everyone involved remembers why things may have changed throughout the development process.

Sticky ToolLook: What are some of the issues you’ve seen agile development teams face with regards to requirements, and what do you recommend they do to avoid those obstacles?

Keith Johnson: Agile teams may have difficulty having customers available as often as they need them. To avoid this, I recommend setting the expectation with the customer at the beginning of the project and educating them on their role and responsibility in the project. It is also important to work out a way and frequency to best communicate with the customer so expectations are again set up front.

Another issue is that one customer representative may not have all of the information required for the entire project. As functionality integrates throughout the product, different customer representatives will have different areas of responsibility and knowledge of the business process the product supports. It is important to track decisions being made by each of the customer representatives to be shared with every customer representative involved in the project. This will allow everyone in the development team and the customer base to be informed and always current so no surprises are delivered at the end of the project.