#SridharPeddisetty #Agile #Kanban #SDLC #Productivity #BestPractices #Metrics #EngagementManagement
“Measure what is measurable and make measurable what is not so” –Galileo
In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban. In this post, we will look at the metrics for identifying bottlenecks while using Kanban as the software development lifecycle (SDLC) methodology. With experience and motivation to improve quality comes working out the right metrics, which measures areas of continuous improvements. In my earlier post 10 Ground Rules on the Right Metrics for Your Business, I had shared some rules on selecting the right metrics that is tied to the desired business outcomes. As summarized in the blog post, data collection, analysis & management is most often cost and labour intensive, so its important to always weigh in against the benefit derived from the selected metric.
One important principle of Kanban is to maximize productivity by optimizing the flow of work and managing work in progress (WIP) by removing bottlenecks. Before selecting the metrics, we need to assess what metrics is needed and then plan on using the processes and tools, which will provide the data for quantification in a shape and form that will allow us to measure. Presently Organizations are competing to provide faster value to their customers, which is effectively done by sizing and decomposing the requirements into minimal marketable features (MMF).
In Kanban, we can have have the Kanban board visualizing the WIP for states and swim-lanes. States could represent the following phases a user story (feature) or defect goes through the development lifecycle
- Product Backlog (Requirements)
- Defined (Analyzed)
- In Progress (Development & Testing)
- Completed
- Accepted
while the swim-lanes could represent WIP for
- Expedite (Priority) user stories or
- Defects (Severity 1/2) or
- Different functional groups such as
- Architecture,
- UI/UX Designers,
- Business Analysts / System Analysts,
- Development
- Operations
- DevOps
- QA
- Technical Writers
- others
In some cases, Kanban board can represent one swim-lane for both expedite and non-expedite user stories or defects while just visualizing states.
Below is a sample ‘Cumulative Mean Lag Time’ metrics, which is measuring the time spent by a user story (USxxxx) or Defect (DExxx) both expedite or non-expedite in each of the following state
- Requested,
- Defined,
- In Progress,
- Peer Review,
- In QA,
- In UAT and
- On Hold
From the metrics we can derive following information including identifying bottlenecks and areas of continuous improvement
- Expedite user stories (US7000 & US7674) are obviously prioritized by the team as the time spent in each state was short comparatively, thus faster overall cycle time. Information can be derived from the chart if the expedite items are distracting the team in effecting their WIP items by looking at the mean lag time an item is spending in each of ‘Defined’ or ‘In Progress’ or ‘On Hold’ states.
- User story ‘US7626’ (second chart) was analyzed, developed, peer reviewed and tested in a short span (~2 calendar days) but spent ~9 calendar days in user acceptance test (UAT) state. One reason for this could be that the user story was not in the priority list for the stakeholders to be released or the priority lowered after the work started. As an opportunity for continuous improvement, we can look at the option where there is an opportunity to reprioritize the user story before the team starts the work.
- User story ‘US7322’ (first chart) spent a lot of time (~25 calendar days) in ‘Requested’ state and then some time in ‘On Hold’ state (~12 calendar days). As an opportunity for continuous improvement, we can work with stakeholders to make sure that we are getting the right requirements and acceptance criteria for the user story along with prioritization. The total cycle time for this user story could be also more because of the complexity and/or dependencies on the other integration deliverables. In either case, metrics shows the bottlenecks and provides an opportunity to optimize work flow for future such occurrences.
- Above metrics also gives the overall cycle time for different sized user stories and defects, which helps in predicting for future work and ability to give a better commitment for the stakeholders
Summary
User Story is like a fish, the longer its sits on the shelf, the less desirable it becomes. Use relevant metrics to measure lead time in each of the Kanban columns (states), which helps to identify the bottlenecks and to improve planning and forecasting.
I will be sharing case studies, process improvements and best practices specific for Kanban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com
