Part One – Key Metrics Needed for Identifying Readiness
At clients where Waterfall has become embedded in the company’s IT implementation strategy and culture, the Agile methodology can be much more difficult to implement in practice than it is in theory. In some cases, specific IT projects may claim to be “using Agile”, but in reality, the project is still predominantly Waterfall – that is, date and timeline driven, heavy on documentation, and segmented into inflexible phases that only minimally run in parallel. During Agile execution, one of the most daunting challenges can be documenting and getting business approval on requirements in a timely manner, and then determining when those requirements are ready to start development. Fortunately, a predominant advantage of Agile is that each client can implement their own version, and eventually find the “sweet-spot” in terms of project structure and flexibility for yielding high-quality deliverables under budget.
Waiting to start development until requirements for a given User Story or Product Backlog Item (PBI) are 100% complete is generally inefficient and impractical, as newfound details, scenarios, constraints, and dependencies are often only discovered once a deeper dive is performed (i.e., usually when development begins). In many cases, Change Requests are used to accommodate for new or missed requirements, although this may effectively decrease the likelihood of being included in the next production release. In contrast, starting development too early, with immature and scant requirements, may result in significant rework and can potentially have an even larger effect of pushing the timeline.
In an ideal project state, requirements are comprehensive and clear when starting development, but in cases where new information and requirements are uncovered, the project’s processes are flexible enough to accommodate and communicate the updated documentation. Most importantly, the teams will be able to incorporate these updates and clarifications into development, based on priority, without significantly impacting the project timeline.
So, this raises the question, at what point are requirements ready to move into development, and how do we identify when we are there? Below are a few considerations that have seemed to work in my Agile experience with Guidewire product implementations in the insurance industry.
Tracking progress of requirements, specifically the estimated percentage complete.
Tracking key outstanding decisions, dependencies, and questions at a high-level, and communicating them to the Project Management team early and often (via recurring scrum meetings, etc.). Generally, these are the high-risk and most complex items, and should represent a majority of the outstanding percentage incomplete for the given requirements.
Tracking Risk for a given PBI and/or User Story’s requirements. This is vital for determining whether or not any outstanding issues could completely change a functional and/or technical approach, and result in significant (re)work. When it is time for sprint planning and committing to development tasks, teams may stay away from committing to items that are 90% complete but still have a high degree of Risk, simply because the remaining 10% could turn into a completely new technical design, a large amount of new requirements, etc. Units for measuring Risk can include a numbering scheme (1, 2, 3…), or even a basic “High, Medium, or Low” approach.
Tracking Complexity at the requirements gathering, development, and testing levels independently. This is crucial for establishing estimates, prioritizing, and planning associated tasks. Complexity is a measurement of how straight-forward the requirements, development, and testing will be, including dependencies on external integrations, pre-work such as environment setup needed for testing, etc. Again, a numbering scheme or “High, Medium, Low” approach may be used.
In Part Two of this series, I will provide an example of a matrix to help track and communicate the various metrics and components discussed above, in order to help provide the key information needed to determine when development should begin, while minimizing the overhead in doing so. I will also provide my thoughts on the definition of “when” requirements are ready for development, based on my own experience, and look forward to hearing whether you agree or disagree.