How do Agile teams handle changes to requirements?

How do Agile teams handle changes to requirements?

Agile methodologies are known to embrace change, but doesn't this come with a price? What happens when other groups have dependencies? Won't changes late in the cycle wreak havoc with the schedule?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Embracing change doesn't mean changing willy-nilly in the middle of developing a user story. We work in small increments, and deliver frequently in short iterations. If our customer sees some early deliverables and decides to make changes, we can do that in the next iteration, maybe only one or two weeks away.

Here's a recent example from my team. Our application automates all aspects of managing 401(k) plans. Our product owner asked for a new report to show a detailed history of employee deferral election requests for all employees within a given plan, and the date each request was approved. As we started on the story and did some research, we realized that an employee's deferral election could also be changed by someone other than the employee, such as the plan sponsor or a third-party administrator. Our system did not log details about those changes, and it was a lot of work to add that functionality. We delivered the report as per the original requirements, but in the next sprint, we did all the work to capture the missing information in the database and provide it on the report.

When I worked for a company with 25 Scrum teams, the daily Scrum of Scrums and the automated continuous build kept teams communicating. If one team "broke the build," they knew about it immediately and addressed it right away. Production releases occurred quarterly, with time built in at the end of each release cycle to resolve any integration issues.

This was first published in August 2010

Back to top