Feb 2nd, 2021
Defining Success
Part 4: Predictability
Written by: Jesse LaDousa, Chief Executive Officer
When we think about defining the success of a software project, several things come to mind. Many immediately think that being “on time” and “on budget” are the most important things. While there is no doubt that these represent two critical pieces, there are other intricacies throughout a project that feed those two overarching goals.
One of those things being the predictability of the team. Hitting the “on time” goal for a project requires a deeper look into how predictable the team can be at delivering on their sprint commitments. During the days of waterfall delivery, predictability was difficult to measure. We had large, long, and complicated phases in which the only measure was the completion of a phase on the date we set (which rarely ever happened).
Today’s agile approach allows for short-duration sprints and makes it easier measure the velocity of the team. Every new team “storms” at the beginning of a project – getting their bearings, learning how to work together, and refining the way stories are written and tasked-out. Velocity can jump around the first few sprints as this storming occurs but in almost every team I’ve seen, the “norming” happens quickly, and velocity becomes constant.
The biggest benefit of this velocity stabilization is that you can very accurately predict delivery going forward. Size your backlog, look at the velocity of the team, and your delivery date for a set of features becomes clear.
The key to accurate velocity is story sizing consistency. The team must constantly learn from their prior sizing and adjust new sizing based on those learnings; adjusting their velocity and commitments accordingly. We typically pick a starting velocity of 20 points per sprint for a small team. This starting point is completely arbitrary, but it’s designed to give us a place to begin and adjust. We size the backlog, pick the top stories that get us to 20 points, and go.
At the conclusion of the first several sprints, a discussion about our estimates and commitments is included in our retrospective. We need to look back at our original sizing to determine if we were correct from a relative standpoint. By this I mean, was the story we sized at 5 actually smaller than the one we sized at 8? If we are comfortable with our sizing, then we move to the number of story points committed to during the sprint. If we committed to 20, did we deliver? Did we deliver more? Less? Whatever the answer, we make small adjustments to the next sprint and then repeat this process again at the conclusion of that effort.
After several sprints of this activity, you will find your predictability becomes increasingly solid. From there, you can confidently discuss your release plan with your stakeholders going forward.