@target-agility Velocity is a metric that tells you how many sprints your team needs to deliver the end product. It helps in forecasting future work. If velocity of your team for last 5 sprints is not consistent then you need to sit with the Team to understand why we are unable to deliver as per commitment done during the Sprint Planning. If it is due to over commitment then you need to talk to the Team about the importance of knowing what’s feasible with the agreed DOD. If it’s due to Team lacking some skills, you need to consider training and knowledge sharing. If it’s due to the dependencies you need to come up with a regular forum like SOS to connect and discuss on risks, issues and dependencies. Velocity is a useful metric for forecasting but it should never be used as a tool to measure Team or individual productivity. SM should coach Team, Stakeholders and Leadership about Velocity and its purpose.
Scrum Forum
Dive into a dynamic learning community. Ask questions, share your insights and enhance your knowledge. Let your fun learning adventure start here!
@pindukuri , a very well-crafted response. Sharing an experience here would have added further. Also, comparing increases in velocity resulting in incurring TD or inflated story points could have also been explored.
@target-agility Thanks much for the response. It gives me some confidence that I am heading in the right direction. I will try to incorporate my real life experiences going forward.
In a previous role, I worked with a Scrum Team that was consistently struggling to meet their Sprint Goal due to low velocity. After analyzing the team's process and conducting discussions with team members, we identified several bottlenecks contributing to the issue.
To address these challenges, I implemented several strategies:
- Facilitated effective Daily Scrum to help bring focus on impediments toward Sprint Goal and progress toward it, ensuring that team members were aligned and aware of each other's work. Developers also started using collaboration tools like Slack or Microsoft Teams for real-time communication and information sharing.
- Implemented a Kanban board to visualize the workflow and identify any blockers or delays in real-time, allowing the team to proactively address issues as they arose. We also set WIP limits for each stage of the workflow to maintain a smooth and steady pace of work.
- Proactively addressed technical debt and process bottlenecks that impeded the team's productivity and efficiency. For this, we allocated dedicated time in each Sprint to address technical debt, refactor code, or improve automated testing coverage. We conducted root cause analysis to identify and eliminate process bottlenecks that slowed down delivery.
- Invested in continuous learning and improvement. For this, we conducted regular Sprint Retrospectives to reflect on past performance, celebrate successes, and identify opportunities for improvement. We encouraged team members to participate in training, workshops to expand their skills and knowledge.
As a result of these efforts, the team's velocity gradually improved over subsequent Sprints, hence increasing their throughput, ultimately delivering more value to the stakeholders.
Having said that, we should maintain a balance between increasing in velocity and delivering value with more emphasis on outcome-based and impact-based metrics over output-based metrics like velocity.
In my experience, too much emphasis on velocity leads to unreliable and dysfunctional behavior like Developers inflating the Story Points to create an illusion of higher velocity. Further, in a haste to increase velocity, the Developers may cut corners and run into technical debt which will make velocity decrease in the long run.
Copyright © 2023. Target Agility. All rights reserved.