Home > Point2 - Process and People > Was Our Velocity Seriously Zero?

Was Our Velocity Seriously Zero?

November 20, 2009

Two Sprints ago something happened for the first time since I have been a Team Lead – my team’s velocity was a big fat zero. As a team we are fairly experienced in Agile and Scrum and quite self-organizing, yet somehow our Scrum board was portraying us as a rookie crew. The first question that may come to your mind is, “did you guy’s have to deal with a lot of production bugs or injected stories?” Sadly the answer would be, no. The team obviously wanted to get to the bottom of this anomalous Sprint so performing a root cause analysis seemed like the right thing to do.

After working through a root cause analysis exercise as a team (this is actually something we do on a weekly basis) we had a pretty good idea of what had contributed to us delivering a big fat goose egg. There were no real surprises revealed, but it did help to get some stuff written down and in front of our faces. On a positive note, the team did agree that even though we didn’t burn up any stories, a lot of work actually did get done. So what went wrong?

  • The was a lot of technical unknowns in the new project we were working on resulting in stories with fuzzy boundaries.
  • The team was unsure when they were done a story, and as a result they dragged on longer than they should have.
  • Our stories were obviously poorly broken down.
  • We were not representing the work that was actually getting done properly on our Scrum board.
  • The knowledge gained from earlier spikes may not have been leveraged to their full potential.
  • We had gotten a little too comfortable in our Sprint planning process. Our previous projects (in the recent past) were usually well defined and understood. Because of this we found ourselves spending less time planning because we could get away with a just in time mentality. This didn’t work for our current project.

Naturally we want our root cause analysis exercises to result in some sort of action plan. With an understanding of what led to our questionable Sprint, the team was able to put some corrective measures into place for the start of the next Sprint.

  • For each story/task on the Scrum board, represent hurdles and stalls visually. Even though we talk about them in daily stand-ups, seeing them on the board can help show severity if it goes on for a long period of time.
  • During our kick-off meeting break down each story into small, bite-sized tasks and use these on the Scrum board. They should be small enough that we have no cards on the board that have a complexity value over 1 – the smallest size possible on our scale.
  • Do not end the kick-off meeting until all task cards are completed, prioritized based on importance and dependencies, and a commitment has been agreed upon.
  • If we find ourselves doing something that is not represented on the Scrum board,
    1. ask yourself if you should even be doing it.
    2. if you should be doing it, write up a new card and put it on the board to ensure that everything we do is tracked.
  • Continue with one week Sprints.

So how did the team fare after putting their plan into action? They met their commitment. The kick-off meeting resulted in a Sprint plan that was straight-forward and well defined. It provided a clear-cut set of tasks that the team could easily base their commitment on.  During the Sprint they were more mindful of the work at hand and made decisions as to whether it belonged in the iteration or not.  As a whole we re-focused on areas that we had gotten too comfortable with and neglected.

It was very satisfying to see the team face this problem head-on. They calmly analyzed it, devised an action plan, and executed it. They could have easily panicked, but they didn’t. They proved that they were a mature team that could recognize a problem, and use their agility to correct it.

By Hemant J. Naidu

%d bloggers like this: