Sprint historical velocity in planning and capacity calculation

After doing this since 2007, my advice is to keep it simple and take the average velocity of the past three Sprints. Many consider velocity and capacity the same thing. Try not counting team capacity in hours for a few Sprints and see if anything changes for the better or worse. My teams dropped adding up their hours over a decade ago. 

Trying to be precise with complex work (i.e. where there is more unknown than known) is like a cat chasing its tail. Story points are simply best guesses. In most Sprints, your plan will never be perfect, but that's okay. There is a lot that can go wrong after the Sprint is planned (e.g. people get sick, people take an unplanned vacation day, work gets added and removed from the Sprint, etc.). But you have the Daily Scrum to replan every day. The Sprint goal provides focus and flexibility for the unknowns.

Focusing on the outcomes, such as meeting the Sprint Goal and delivering a valuable increment, is much more important than getting velocity correct and having the perfect plan. In fact would anyone care if your velocity calculation was perfect yet no one wanted to use what you built?

Embrace uncertainty, get comfortable with uncertainty, and use change to your advantage. That's what agility is about. 

I think you're going about this the wrong way. You're starting from velocity, likely in an attempt to fill the Sprint with work, instead of starting from a goal and checking the effort needed to complete the goal instead. The word "goal" or "Sprint Goal" doesn't appear anywhere in your discussion of planning.

You know that you can likely get somewhere between 27 and 32 points of work done, depending on exactly how you calculate capacity. But what goal do you want to achieve? And how much effort will it take to accomplish that goal?

If you can craft a Sprint Goal and then select the Product Backlog Items that the team believes must be Done to achieve that Sprint Goal, can you figure out the size of those items? If so, is it more than 32? If so, you almost certainly need to replan, likely by revisiting your Sprint Goal. If it's somewhere between 27 and 32, there's a risk, but you can monitor. If it's less than 27, then you may be fine.

Regardless, even after you achieve your Sprint Goal, you can still pull Product Backlog Items from the Product Backlog. By the end of the Sprint, you'll be able to count the amount of work that the team got to Done and use this in future historical calculations of velocity. But I'd continue to recommend the same approach: craft a Sprint Goal, check effort against capacity, replan until a goal fits into capacity.

As far as calculating capacity, I'd recommend planning at 75-85% of the average of the last three Sprints. In your particular case, the rolling average is 30, so I'd plan on somewhere between 22 and 26 for the goal, and then be ready to pull additional work if time permits. However, the percentage tends to be a function of the risk tolerance of the organization. An organization that prefers to be more conservative and create goals that are more likely to be attainable would likely be closer to 75-80%. A more risk tolerant organization that is willing to reach and fail to achieve a goal may target 85% or even the 90% that you propose. I wouldn't recommend going above 90%, just to leave room for the unexpected.

Scrum is aimed at complex challenges and people themselves are complex. If it was possible to manage things by the numbers, you wouldn't need Scrum at all.

Capacity is not a science and we are not story point accountants. Risk and uncertainty are endemic, so encourage the Developers just to get their arms around how much work they think they can take on each Sprint. Everything else reduces to value delivery and empirical process control. Capacity is less important than the contingency the Developers reckon they might need, roughly considering the variables they know about, to meet their Sprint Goal commitment.

The whole idea of using Story Point is to relatively estimate because we can't accurately plan each task in hours or man days. Matching the history of work done may not also help to plan the future work because lot of factors will be different. If the team spend time in detailing the estimation, they may loose the focus in doing what is valuable. 

Maybe you are overthinking it, I have had quite some success taking the historical velocity as a conversation starter to check if the team can achieve their sprint goal or to help them not to overcommit (we all know that PO). You might not want to put that much emphasis into these metrics and become overbearing. 

There might be something more to it depending on how is the company culture and how mature is the team. For example if they are misusing Velocity outside of the team to measure performance or if the team is not mature enough to speak openly.

I agree with the other comments the approach is to complicated, and story point estimations are just an estimate, don't try to get it accurate to the story point.

A slightly different focus. It seems the team is presented with a story point number that they need to plan against. Rather allow the team to self-manage and let the team decide what they can pull in and what is achievable. Define an achievable goal with the team, and let the team decide how best to reach the goal. The team should decided how many items can be pulled from the backlog and what is an achievable sprint plan. Start with a goal and pull items in, and use the velocity number only as a rough indicator of an upper limit, to prevent over planning.