I decided to post this today as I had a conversation with a colleague who was struggling with the concept of velocity what it means, how it is applied in terms of sprint planning. He was struggling with a product owner using velocity to predict what could fit into a sprint and the team using it as the definitive line of what they could work on. As surprised as they were, I said, this is how velocity can be used although it should be seen as a radiator of information, not a definitive prediction for future work.
He was also very surprised when I told him that using velocity was dependent on how planning was approached as it might not factor at all. (insert head scratching here)
I explained that based on things I had learned from a planning and estimation course (thank you Mike Cohn) that there were actually 2 potential approaches that I was aware of when taking on sprint planning by a team.
- Velocity Driven Planning
- Commitment Driven Planning
The former, as the name holds makes velocity a primary point of measurement for determining team capacity while the latter uses available team member capacity as the point of measurement.
Velocity Driven Planning
This is the type of planning that is most commonly used, from my experience, and most commonly taught in scrum classes that I have attended. This is the process by which a team will determine it’s maximum team velocity based on past delivery to determine the level of commitment that they feel they can make in the current sprint. This is a view typically based on a historical perspective. That being said, velocity is helpful over the longer term when consistency shows the actual velocity of a team as opposed to the sort-term. And any disruption to that team means a potential change in their velocity. It is a radiator of possibility, not an absolute.
This is the process where a team may look a sprint or two behind (successes and failures are fine) and together determine level of commitment in terms of points that it can make commitment to based on that ideal.
A team may look across several sprints, add the sum of total points delivered and divide by the total number of sprints to arrive at an average maximum velocity for the team. This will be used to set a maximum velocity for commitment by the team.
Capacity Driven Planning
This approach is much more focused on the amount of available capacity to each team member to meet the task obligations so that they can apply this capacity to the items when decomposed to determine when they feel “full” as a team in relation to the overall hours they can utilize.
This process uses the following process flow:
- The team members determine how much capacity is available to the for the sprint. This can be determined by factoring in capacity for organizational overhead (meetings, personal time off, etc.) plus a projected maximum timeframe for unplanned work (such as support responsibilities, emergent tasks not identified or other items that may come up; as we never want to plan for max capacity typically) subtracted from the available determined timeframe for the sprint.
- The team will select a story from the backlog with the highest priority and decompose the work into the basic tasks that need to be completed to deliver the story and attach an estimate of the amount of time projected to complete the work in hours.
- The team members will take the decomposed items and apply it against their projected capacity (if development work the developers may need to discuss how the time applies across multiple people with same domain specialty). Once deducted, they now have their remaining capacity and repeat steps 2-3 until they have filled that capacity close enough that the team members are as full as the team can carry for the sprint. This will not always be the case for every team member.
This approach is focused more on the short term as opposed to velocity as it uses a projection of time over the next sprint period and the capacity of the team for that sprint work. Using this as a baseline after the given sprint would not be a good idea as the first step should be that the team members calculate the available capacity before each commitment.
This approach can be much more time consuming as the team is decomposing the work as it goes along to measure each item against remaining capacity before it makes the commitment to the given story. You have to be vigilant that a team does not get caught up into so much perfection of task decomposition that they make this meeting long, painful and less productive.
Which Should you Use?
Get ready for the answer you will love to hate. It depends.
If your organization has team members not really following a focus of scrum or they have them handling other responsibilities, then capacity planning can be really helpful (and a savor for those that think the developer who can focus 1 hour a day has 8 hours to work on a product).
If your team velocity is all over the place or you have a sense that the team has fallen into a comfortable groove and never pushing themselves because it’s “easier”, maybe capacity planning is something to try.
If you want to find that sustainable pace that allows your team to use past information to give them insight into a future prediction, velocity can certainly help you do this.
Do you have a product owner that thinks in terms of features and not in terms of sprints? Either of these methods can assist you to help them understand how to create that bridge of trust with the team to understand what goes into what they are asking to accomplish.
A general rule of thumb is that if you look at the velocity of a team you will see some variance over time (based on team member availability or unplanned work) so it is really just a guide. Using capacity, you are trying to apply a more concrete form of measurement to the work at hand (although there is room for error here as well as things take longer, unplanned work takes up more time, etc.) but it is based on what the person expects that they have available to commit in terms of the value they provide to the team.
What Have I Typically Used?
Most teams I have worked with have used velocity as it feels easier to them than to determine their capacity and fortunately I have been able to minimize the distractions they have from product focus. But, I would be open to change if needed or to experiment. We often determine capacity for team members (like leave, etc.) at my organization with them just so that we can make visible to the team the drop in team member involvement so they can consider how this impacts their commitment.
My Observations of Team Planning Meetings
What I will say is that often times, from what I see, teams do not utilize planning sessions to the utmost effectiveness. They tend to rush to commit, rush to decompose so that they can start working on building. It often feels as if they are just trying to put something down and move on. It is our responsibility to help them understand that this is a time to refine the understanding before the energy of work begins.
Some teams do not use the time of these meetings to discuss architecture and design much or talk about approaches. They merely try to identify the tasks, drop some numbers and move into the work. This is a failure on our part of servant leaders if they do not realize that this is a horizon for which they can better understand the work based on the known today. If using the general scrum rule of thumb for 1 hour planning and 1 hour tasking for every week of the sprint, these can be long meetings for some teams.
A 30 day sprint alone could be a full day meeting. Why not use it in the best way possible? I get it, I have been a technical team member and was ready to build but the greatest power I found from the team was that we saved time when we came together, discussed and white-boarded ideas BEFORE we ever leveraged code. We maximized the time to gain a shared understanding of work that we could reflect and adjust as well as understanding the items we would be building. Approaching our sprints in this manner allowed us to create a shared and unified approach even if the path to get there was evolving throughout the sprint.
One of the best comments I ever heard about sprint planning is that it is far less important to be precise in identifying each and every individual task for a sprint than it is ensuring that you understand the stories to be delivered that make up the commitment as a team.