Part Two – Tracking Key Metrics and Identifying Readiness
In Part One of my two-part blog series, the importance of finding the “sweet-spot” in regards to the timing of starting development on documented requirements in an Agile project was highlighted. Specifically, it was noted that identifying “when” requirements are ready for development can be a very daunting challenge. In summary, a few of the key metrics needed for making the decision to start development, based on my personal experience with Agile projects in the insurance industry, were highlighted:
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 this segment, we’ll consider tracking these metrics using a matrix to provide the vital information needed in determining when development should begin, while minimizing the overhead in doing so. Additionally, I’ll provide an overview of the general approach that I’ve seen to work in terms of defining “when” requirements are ready to begin development.
One example of a matrix which tracks key metrics including Progress, Risk, and Complexity for a given set of requirements has been provided. Keep in mind that there are countless variations of the matrix that can be used. For example, any of the parameters can be weighted, rounded, or even grouped together as desired to make the matrix either more detailed or simplistic. For instance, rather than a standard calculated average for Complexity per Backlog Item, some teams may elect to use a single value, or possibly a weighted average that is heavier on the Development factor, etc.
###2F1Et1OyFFw46cIhtj9IAn###
Given the parameters and data provided in a matrix, teams can leverage the information to make better decisions on development prioritization and planning.
So, this leads us to the question of exactly “when” development for given requirements can begin? In my experience, a general approach that has seemed to work, in most cases, is as follows:
Start development on requirements where elaboration is 80-90% complete and development has a Low to Medium Risk level.
Encourage starting the legwork early on items where the overall Complexity level is High and the development Risk level is Low to Medium. This is where teams need to use their expertise and discretion, however. + In many cases, a majority of development work can be started on more complex requirements or functionality, as long as the portions being worked on are not subject to the high degree of Risk that exists from outstanding questions, decisions, etc.
Additionally, some teams have found it useful to create a matrix of the parameters for assisting with the Estimation process of new User Stories and Backlog Items. Of course, there is some overhead to this process, so each project and team can modify the way this information is being tracked and used, as the project continues.
In summary, not all User Stories or Backlog Items are the same, and there are always exceptions to the rule for how they must be handled. The discretion of the highly intelligent and experienced resources that I’ve had the opportunity to work with on various projects has always been the best tool for making these decisions. Perhaps as importantly, is the degree of effective collaboration that occurs between the Business Analysts and Programmers during development, which I think I’ll save for another blog topic. With all of that considered, what general approach(es) have you seen work, or not work, when making the decision to start developing requirements on an Agile project? Your feedback is greatly valued and appreciated.