Tracking changes to requirements in Agile development
All development teams need to track requirements changes, but depending on the software development lifecycle and overall ALM process, the best approach to change tracking may not be the same across the board. In this response, expert Mike Jones explains how Agile teams can best integrate change tracking into their development process.
What is the best way to track changes to requirements?
This is a loaded question that depends on many variables and requires a unique answer for different development teams. You have to consider the problem domain, your software development lifecycle (SDLC), and overall ALM process. Of course, problem complexity and the ability to deliver well-defined, stable requirements will impact change tracking as well.
From my experience with delivering custom business applications, the best way to track changes to requirements is by using an Agile SDLC and let your development process take care of the problem. By that, I mean:
- With most Agile approaches, you do not try to capture formal requirements. Instead, you start with high-level objectives and use case-driven features aligned to individual users. We practice this at OutSystems, as we have found that aligning a feature to individual users ensures that you don’t overload a given feature definition.
- The next step is to simply work in a priority order and use the working application to decide, with all stakeholders, if the requirement is complete. Of course, you do this on a rapid (sprint) iterative basis, ideally spanning one to two weeks. Working this way constantly refines the real business needs (a.k.a. requirements) and aligns them with priority and available resources, resulting in a very lean business application. Tracking change becomes inherent to the process -- simple, efficient and elegant.
So, what’s the best way to track change? A simple email after the sprint review meeting will do. By sending these wrap-up emails, you ensure everyone is kept up to speed on what was decided in the meetings, and you keep a lightweight historical record of the project. It’s the Agile way to do it.
