Tracking Software Development Team’s Output Velocity
How can leads really say that their Team’s performance improving consistently?
As a Software Development Team’s Lead (Manager, Director alike), you would like to know if your team’s delivery velocity is improving. Unlike Manufacturing where delivery velocity can be easily tracked, can a Software team’s velocity be really tracked through Metrics? Can those Metrics help in identifying in any risk, team dynamics issues , or need for training etc.?
Difficult Life of a Software Development Lead
Software Development Lead intrinsically knows that team’s delivery Velocity and quality is improving consistently. Yet on most of the occasions leads do not have Metrics to look at; and hence may not be able to take Optimal/Timely Decisions to improve their team’s Delivery.
Tracking Delivery Velocity
In this article we will talk about Speed of Delivery; in forthcoming Articles I will talk about tracking Quality of Deliveries, Business Impact of the Deliveries etc.
Prerequisites:
- Awareness of Scrum/ Agile for solution delivery.
Process:
Software Development Team work on Stories Prepared and Assigned by Analysts. Team delivers the stories within Sprint Cycle.
As part of sprint Grooming/Planning/Pre-Planning most important piece of information that is required is the Story Point. I will not cover the philosophy or the Process of assigning the Story points.
Only piece that I would add is to ensure that Story Point computation and assignment process should be consistent every Sprint Cycle.
During Sprint Retrospective — capturing the Velocity (summation of all Stories Delivered) is another important Step. Any Story that is partially delivered should only contribute partial (proportion of Completion) Story Points to the velocity.
Analysis:
After few sprints, Leads will start getting some picture of Average Velocity of their team.
Ideally Average Velocity should ascend slowly indicating improving team’s Delivery capabilities.
In general this data is also extremely valuable to
- Commit to your Stakeholders on what your team or can not accomplish (Based on Avg Velocity)
- Understand if there is any need for training (New Technology, New Team Member etc.) — When Avg Velocity goes down considerably
- Mitigate any Risks — Code getting hard to maintain/ Technical Debt or any team dynamics issues etc.
Overtime Velocity Data, can be sliced and diced in multiple ways; though it can never be looked at in Isolation. Team’s Demographics, Dynamics,Overall Capacity, Changes in Stakeholders etc. should also be considered; before any direction for mitigate (or not mitigate) any Delivery Risk.
Overall
A Development Team Lead has to understand their team’s velocity so that they can ensure that Team is improving overtime and such data would also help them to
- Have Consistency in Commitment and Delivery
- Ensure that any Risks in Delivery are understood/ and mitigated
- Any Training Needs or Technology Debt are understood and addressed
Any Suggestions or Questions are highly appreciated.
P.S: Curious about Tech Debt? Refer to my earlier Article:
