We are approaching our two year mark since we began the Agile Transformation in our organization. In the last two years, we have attempted to capture and report several metrics for the success of our Agile adoption. Some of the metrics we tried included Velocity, ratio of committed to completed items, defects, burn-down charts, etc. The measure of team’s Velocity outlines the number of story points your team can complete successfully in a given iteration. Using velocity, your team can estimate the number of iterations or the duration for completing a given feature. The Ratio of committed to completed items would shed light on the effectiveness of sprint planning and the execution of the sprint. The burn-down charts would guide your delivery team  by providing the estimated amount of work to be done. While each one of these metrics serve the team in some form or the other, they are often skewed toward measuring and monitoring development work, falling short of presenting the bigger picture.

Given that each feature, project or a program begins with planning, I believe the true measure of Agility can be represented by the entire duration for Discovery (Ideation) + Delivery activities.

In other words, Agility of your team or organization is determined by the time it takes from the Creation of an idea that aligns to your product vision to the Shipment of your code for live-user engagement. For example, if it takes two months hashing out an idea and two sprints (assuming a 2 week sprint) for developing and releasing it, the measure of agility for this feature is simply – three months. It is more likely that your senior management would connect with this metric rather than indicating that your team had a velocity of 40 story points for two sprints.

Why does this metric matter?

• The transformation from Waterfall to Agile methodology is often misconstrued as merely adopting Scrum or Kanban in the engineering process.
• Using this metric, your team could identify areas where improvements can be applied from the ideation to delivery of features.
• Through practice and discipline, your team can begin adopting agile techniques for shortening the total duration.
• While velocity and burn-down charts aid the delivery team, representing the time it takes to validate ideas would serve your product owner and user experience members.

Typically, both discovery and delivery activities happen in parallel resulting in a continuous improvement cycle. While techniques such as pair programming, refactoring, etc., aid the development process in being Agile, the efforts and approach leading up to initiating development work often remain unmeasured.

Discovery activities are crucial to building the right features. Similar to engineering activities, discovery must be time-boxed. Some of the discovery activities include:

• Creating ideas or evaluation of requests that support your product vision and KPIs.
• Performing user-testing and seeking validation on your ideas or concepts.
• Iterating through wireframes and prototypes.
• Engaging in Story Telling and Story Mapping exercises with your team for creating user stories.
• Other activities necessary for your delivery team to begin development work for creating potentially releasable code.

Your team can apply lean principles for shortening and gaining confidence with discovery activities. Once the product backlog is ready, your team can then iterate through development, perform automated testing, and release it to your sandbox or production environments.