My fellow PST, Glaudia Califano, and I were sitting in a café (at a time prior to the current lockdown due to Covid-19), having agreed to meet up with a Business Analyst who had reached out to us to have a chat about Scrum and Agile. We are never too busy to pass on having coffee, so we agreed to meet and have a chat.
Once we’d settled down with our lattes and macchiato (I’m usually a flat white person, but it is always a small caramel macchiato with skinny milk for Glaudia, just in case you ever need to know!) and made some Scrum small talk, the Business Analyst came onto one of the things that had really been bothering him.
“Our problem is that we can’t plan Sprints accurately with velocity,” he said. “Some Sprints, our velocity is really high, in others, we barely achieve anything.”
There could be many reasons for what our new friend was describing. We needed to find out more about the context. Perhaps this team just needed some time to understand what their measure of velocity meant to them (they were using story points). Things would stabilize over time and they would arrive at a more predictable velocity range. Or, maybe the Scrum team suffered from instability in its membership, with team members being swapped in and out, disrupting the team from finding out the best ways of working with one another.
Digging deeper, we found out that the team in question had been working together for several Sprints, long enough to form a good understanding of what their story points meant for them, and the team had been stable over this time.
We continued to ask questions. “Are Sprint Goals being met?” was next. After all, in Scrum, it is the Sprint Goal that should be the focus for the Development Team, not hitting a particular velocity or getting a set of Product Backlog items done.
This started an interesting conversation and a pattern that we see commonly emerged; teams not crafting a Sprint Goal during the Sprint Planning event. Sure, we have seen teams forecast that a particular set of PBIs will be done, but this is not the same as creating a Sprint Goal that makes it clear what outcome will be achieved when the goal is met. Sprint Goals should be crafted by the Scrum Team in collaboration. The Development Team has the final say on which PBIs it forecasts for the Sprint to satisfy the Sprint Goal. The purpose of completing PBIs is so the goals of the Scrum team are met.
“Are PBIs getting done in a Sprint?” was our next question. According to the Business Analyst, they were in a good place in that they had a Definition of Done and so they had a clear, shared understanding of what it meant for PBIs to be complete. What he revealed next though, was that very often, PBIs forecasted for the Sprint during Sprint Planning were not always completed during the Sprint, and were commonly carried over into the next Sprint.
Getting to “done” at the end of every single Sprint is the purpose of Scrum. When teams are unable to do this, Scrum is actually providing an opportunity for the Scrum team to inspect what is preventing it from doing so. It could be that the team has too much to do at once, or the PBIs are too big or vaguely defined. Whatever the reason, if a Scrum team has an inability to regularly get things done in a single Sprint, if they end up regularly putting items back on to the Product Backlog or carrying them over from Sprint to Sprint, this is going to add complexity in trying to plan Sprints based on velocity as the numbers are likely to be fluctuating wildly. There are a whole host of other (and more important) reasons why getting to done every Sprint is such a central part of Scrum, but I won’t go into that here.
As well items that were going back on to the Product Backlog, we asked about items relating to those that the team thought were done. What we were looking for here is quality. Whether it is escaped defects, technical debt or simply features that were released that did not meet customer expectations, work that comes back to the Development Team is going to add complexity and disrupt plans, especially if these items are making their way straight into the Sprint rather than as new PBIs on the Product Backlog. Instead of accepting this as normal, the real question the Scrum team should ask itself is, "what can be done to prevent these issues occuring in the first place?"
Velocity can be a useful indicator as a guide of the Development Team’s past performance. It is however, a complementary practice in Scrum and like any tool, it has its limitations. It is not suitable for all teams and all situations, such as the one here where the team’s velocity varies a lot. One alternative to velocity based Sprint Planning is capacity based Sprint Planning.
We told our friend about how capacity based Sprint Planning works. Start by working out roughly how much capacity you expect to have available for the Sprint. For example, your Sprint may be 2-weeks long and you have 5 Development Team members. One thing we do is assume 6 productive hours per day. So that gives us 10 days x 5 people x 6 hours per day - 300 hours of capacity. At the Sprint Planning, we would ask the team if there are any other expected drains on our time, such as people having booked vacations or other meetings in the calendar.
As the Development Team breaks PBIs down into tasks during Sprint Planning (by no means a way of working prescribed by Scrum, but a common complementary practice nevertheless), it estimates the tasks in hours. Planning continues until the team runs out of hours. Of course, we expect further complexity to reveal itself during the Sprint, so we may only plan up to ⅔ of the available capacity. It’s not perfect, and not for everyone, but we have found that where we have used capacity based Sprint Planning, the Development Team thinks even deeper about what they need to do during the Sprint and they end up with more realistic Sprint forecasts.
Why is making accurate Sprint forecasts important anyway? Scrum is a framework for addressing complex problems, and Scrum teams that can reach a cadence where their goals are regularly met are going to instill more trust, manage stakeholder expectations and manage that complexity sustainably.
We finished our coffee and parted ways, our new friend buzzing with new ideas to try with the rest of his Scrum team. Though this may have been just the effects of the caffeine!