Resurrection of our sprint velocity
In this post we’ll be discussing the exact steps my team took, which helped us, in improving our sprint velocity. We’ll also review what is agile methodology of software development and the purpose it serves.
Our intention is to have a better understanding of agile methodology. Also why & how we can improve our velocity.
Scope creep is one of the topmost reasons for projects failure. The ever changing requirement is inevitable. Another way to address this, is to make the team agile enough, to cope up with changing requirements.
Agile methodology is a framework or set of best practices that helps in bringing in agility into software development. It’s not a rule book that we must follow, rather it suggests a few guiding principles. We can modify them, as per our use case and adapt.
Stay aware. Adapt. Change. — XP
One of those principles, suggests teams to commit to a little scope of work and work iteratively in small cycles (usually of 2 weeks). So that, any change can be easily incorporated, without wastage of much resources. After each cycle, the team retrospects & reviews backlog features, which is of the highest priority and work on them next. This cycle is called Sprint or Iteration.
Whole idea behind working in small iterations is to make small commitments and consistently deliver on them. I noticed my team is doing good. At the same time, I also felt, that we can do much better. So I jumped on to the driver seat (as an improvised scrum master) and anchored the drive to improve velocity.
Find a starting place, get started, and improve from there. — XP
These are few things which helped my team in improving our velocity by ~50% (from 50% to 75% completion):
New pair of eyes bring in new perspective:
As I was new into the team, I was not biased with existing ways of working. So I perceived things a little differently. This made me question, why we do certain things in that particular way. Eventually, discover few bottlenecks, which might otherwise have passed unnoticed, due to pre-existing bias.
Alignment within the team:
One of the very first things that I did, to start with — was to schedule meetings with team members. I wanted to understand their concerns, thoughts and context better. I also took this opportunity to make sure everyone is aligned on why we need to improve our velocity.
Trying to achieve a goal with people who are aligned on the goal, is one thing and trying the same thing with people who don’t believe in the goal, is different. This was the first thing we did right.
Present ideas in visualized form:
Another thing which I did was to use the various reports auto-generated by Jira to articulate my points. I always showed them the burnup, burndown and velocity charts.
Data-driven scrum master — feedback
Proper backlog grooming:
In backlog grooming, I made sure, everyone understood — why we are prioritizing a particular feature. I tried to explicitly bring out the value props of each ticket. As a result, we have a better picture of what exactly we’ll be working on in the next sprint. This indirectly helped us in better estimation.
Let’s not overcommit:
As human beings, we have a limit to how much we can stretch. Beyond a certain point we can’t go. So it’s very important to retrospect and see how much work we are able to complete comfortably and then commit according to that.
Under promise. Over deliver.
I started asking people, are we sure we’ll be able to complete every ticket that we’re signing up for, in this sprint itself ? This helped everyone retrospect and commit better.
Let’s not allow scope creep:
I personally made sure that people understand, why it’s an anti-pattern to modify the scope of a sprint or estimate of a ticket, after committing to it (hotfix/urgent tickets are totally valid). If we keep adding tickets even after start of the sprint, it’s like trying to achieve a moving target (burnup chart helped me in articulating this very well).
Resolve bottlenecks by helping each other:
We identified few bottlenecks in our workflow. For example, only our team lead used to code review, I along with other devs decided to assist him. We felt that QAs are getting a bit overwhelmed by the number of tickets in QA lane, so we devs started QAing our own, non-critical tickets. This helped us in moving fast.
Let’s not over stress upon the numbers.
Here, our only goal is to deliver what we commit to. And commit only, as much as, we can deliver.
Excellent team work. We pulled off this feat, together!
The whole is greater than the sum of the parts — Aristotle
