Increasing Sprint Capacity
One of many mistaken ideas I held when I first got into Agile project management was that over time a Scrum team should be able to increase its overall velocity. The scenario I had in mind assumed that the team was stable and had become consistent on forecasting story point values (commit vs complete). The problem begins right there, with those two assumptions, and goes much further. There are ways to improve team velocity, but there are limits.
First, although a team may be fortunate in remaining stable over a period of months or years, this is not something I've found to be the case very often. Team members come and go, sometimes because they're reassigned and other times because people naturally come and go from the company. One often overlooked source of instability is out-of-office time, whether through maternity/paternity leave, vacations, or illness. Capacity planning can be challenged by any of the foregoing factors, and it's simply a part of life.
Second, velocity may remain the same while quality improves. I had the opportunity of working through an Agile transformation with a mature team of professionals who had worked together for years by the time I came along. They were already accustomed to one another, and the Agile mindset made their existing team and workflow transparent and even more collaborative. This is a team that I fully expect to maintain roughly the same velocity, while the quality of their work output will improve. This means less technical debt and eventual refactoring time, a win for them and the business.
Third, by the same token, higher velocity can come at the expense of velocity. The class project management triangle applies here. Any stress on time, scope, and/or cost of a project will ultimately impact quality. Cut corners include reduced testing and reviews, and that spells trouble. Being Agile does not exempt a team's projects from the simple fact that being pushed to move faster will result in a product that might be high grade, but of diminished quality.
Fourth, what do the story points mean, anyway? My teams always use the fibonacci sequence, capping at either 8 or 13 for any particular story before it needs to be broken down further. Looking across several teams in the same program, I see that the meaning of those story points differs to varying degrees between them. As teams change over time in composition and experience, the meaning of those story points can change as well. Granted, this usually takes so many sprints that it doesn't matter, so long as we only evaluate based on the most recent 3 or 4 sprints, but it shows that story point values are mutable. A team might actually be delivering a greater quantity of items in its product increments over time, and still evaluating things by the same story point numbers because their understanding of those values has changed without them noticing.
Velocity is a very important metric, but really only in the short run. As I've said, the average of the most recent few sprints is the most useful in terms of predicting capacity. It's not a long-term measure of quality or output.
There are some ways scrum masters and Agile coaches can facilitate improved velocity, staying within their area of professional expertise.
One is to optimize sprint planning meetings by helping the product owner and team do refinement a few sprints in advance, whether in the formal sprint planning meeting or without. A couple of my current teams add, curate, and refine their future sprints collaboratively over the course of the current sprint, leaving final prioritization to the product owner, and allowing for further discussion/negotiation in the sprint planning. This gives everyone access to the big picture and helps sort out inefficiencies.
Another means to improve velocity is to use the sprint retrospective effectively, helping the team fine-tune their process by evaluating their strengths and where they need to make improvements. Personally, although I think all the ceremonies are important, the retrospective is right up there with the daily scrum at the top of my list. One encourages reflection, the other collaboration, and both help remove immediate or recurring blockers. The gain in efficiency can show in velocity.
In sum, beware of making increasing velocity a goal for the team, regardless of how long the team has been together, and how stable its composition. If the Agile team and the stakeholders of their projects are satisfied with how product delivery is going, that should be enough. If not, then more inspection and adaptation is required.
