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,
- ask yourself if you should even be doing it.
- 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.
In last week’s post I talked about how a stakeholder can use Value Points as a useful metric, and how to assign Value Points to epics. Value Points are good for determining whether the team is working on the right projects but they don’t paint the entire picture. This is where Velocity points come in.
At Point2, we estimate story sizes based on relative complexity. The simplest thing we can do is a 1, something about twice as difficult a 2, and so on. Some people prefer time estimates, either method of sizing stories is fine here.
Once you have both Value and Size estimates for your stories, you can plot them on a scatter plot. Here I plotted story size on the X axis, and Value on the Y axis. Small size, high value stories are in the upper left quadrant, low value, large size stories are in the lower right. In this example, I would probably get the team to do all but 3 of these stories, those being the ones with size 5, value 2 and 3, and size 3, value 1.
The interaction between value and size is an excellent way to make sure your team is delivering the right product. High value, low complexity stories are great for delivering some quick value, possibly as a means of generating the capital to tackle the larger projects. Low value, high complexity stories might be best left on the shelf, or alternate means of solving the problem sought.
By: Tefon Obchansky
When Point2 adopted Scrum over a year ago we started with 30 day iterations. The process was new to us and it seemed like a reasonable starting point. As we ironed out our practices and got more experience we naturally started to make changes to improve how we did things.
After running through a few 30 day Sprints we soon realized that they were just too long. We were finding that at the end of the Sprint we were unable to remember what we did at its start. This became glaringly apparent during retrospectives. The decision was made to move to two week Sprints, and that is they way our six teams have been operating ever since.
My team had been throwing around the idea of shortening our Sprints even further over the last few months, but at our last Retrospective we decided to actually take the plunge. Even though we were being reasonably successful with two week iterations, we still felt that we could go faster. One week (5 day) iterations seemed like a good way to help take the team forward. Here’s how we think the change will affect the team.
- Even though two weeks was not long, it still left enough room for a large amount of stories to be part of the Sprint. This meant we had a broad focus. One week iterations would allow us to easily visualize the Sprint. Our focus would be much sharper
- One week Sprints would hopefully allow us to better accommodate change that comes in an Agile environment.
- With weekly retrospectives would come more organized discussion to fine tune our process even further (that’s not to say we would not continue to make mid-Sprint changes if need be).
The team plans to make the transition at the start of the next Sprint. We understand there may be a bit of extra overhead in regards to planning and estimation meetings, but feel that these will get considerably shorter, having less impact on the actual Sprint.
Without actually having tried it yet the team just has a “gut” feeling that this will make us go faster. Just think about it for a second. If you are in a 400 metre race, you will have to run at a slower pace in order to finish. Cut that race down to a 100 metres and you should be able go to all out. I look forward to seeing how this will impact the team and will do follow-up posts reporting on our progress.