Story points are pointless, measure queues

It didn't even occur to me think of it this way, because the times I've been exposed to breaking down tasks the total number of points stayed constant. 13 pointers becoming an 8 and a 5, and the 8 pointer becoming a 5 and a 3.

First, the SAFe explanation. I've been a software developer for a little over 22 years. My first experience managing a team was 12 years ago and I shifted to it full time in 2018. My entire motivation for doing this was living through environments that were painful and unproductive for everyone involved.

I found Reinertsen during a lot of reading when I was trying to learn the best ways to do things and get a clearer picture of things that I didn't understand because I hadn't had a view of them in my dev/arch/ops roles previously. When I picked up that book I periodically shouted, "YES! EXACTLY!" while I was reading because it showed the math to prove just about everything I'd experienced. Then I used his methodologies to lead two teams with a great deal of success from my perspective.

What I was not doing a good job of was communicating with the business side of the company regarding what was prioritized, why and how. That lead to a lot of back channel grumbling from other people in leadership who had different priorities. I'd just spent months talking with everybody about what their priorities were and mapped out a plan to have it all done in about 6 months. I was extremely confident in this plan at the time. It was beautiful.

One of the senior guys, who I will call "Squeaky Wheel" torpedoed the plan because his top priority wasn't first. That was the moment that I realized I needed to find a better way to get these folks involved in the process that wouldn't blow up all of the great things we had happening.

Long story short, I found SAFe and the CEO sent me for training after I explained my rationale. Here's what appealed to me about it.

1. WSJF - All facets of the company come together to agree upon the value of different initiatives. Sales, Support, Product, Legal, Marketing and other senior leadership when necessary. Following the discussion all of the back channel "we should be doing this" stops because everybody knows exactly why we're doing what we're doing.

Then you combine that with an effort estimate to get a projection about the best value for your time. This will naturally end up prioritizing a bunch of small stuff that has been ignored for a while first, but once you get through that you start more cohesive conversations about larger initiatives. In that first experience, Squeaky Wheel had a low value high effort project that went to the bottom. Aside from him, it went beautifully for everybody else.

2. The PI process - After people have put in the effort to agree on priorities, PI planning happens where Dev gets to lay out the plan for the best way to achieve those priorities. You spent a couple of days planning it, presenting, reviewing and everybody comes out knowinng what the priorities are for the next 8-12 weeks. Then as a dev you get to execute without dramatic shifts in direction. Now, when somebody in sales doesn't close and tries to make a case to change everything you're doing he's directed to make a case to product for WSJF consideration for the next PI. This brings sanity to the dev process.

The PI plan also involves capacity planning so you build in a natural buffer too. As a side benefit, you find out most of the vacation plans of your teams over the next quarter well in advance. One of the big goals of PI Planning is building camaraderie and skipping future meetings with people who may need to provide input. This factor is significantly more difficult in a remote environment.

3. The "Solution" Backlog - Part of the process is that dev gets to keep and prioritize its own backlog of technical priorities for the next PI. You typically split the capacity planning 70/30 or 80/20 across the Feature/Solution backlog. This gives the tech side of the house the ability to ensure work that they know needs to be done, gets done without having to make a case to the business about why. This gives time to improve processes, automation, reduce tech debt, refactor, performance tune, etc if it hasn't already been built in.

When those 3 things happen every developer's life should get easier. Unfortunately, it doesn't always work that way and you'll end up with more layers of control + dictation rather than handing over control to interested parties.

There will always be something else to do, that is definitely true. In this context we are talking about taking a chunk of that and trying to create an expectation of when it can be ready.

In a Sprint, for example, you take a slice of work from that queue, a few stories with the goal of trying to get it completed in the next couple of weeks (hopefully). That creates a new queue for the sprint, essentially.

You've controlled the flow of work based on the teams historic capacity using some metric, which has previously been velocity.

Overloading that capacity is what happens when new work sneaks in. Support items. Requests from people outside the team. Long meetings. A team member unexpectedly being out. Either the amount of work has gone up or capacity has gone down. If anything that was planned is much larger than initially expected, you're going to end up way behind. That will push everything else farther behind at the same time.

The moment you start scrambling to try to get it all done, you're going to start making mistakes. People are not going to take the time to refine things. Errors will happen. They'll take longer to fix or worse they'll end up in production and create new problems...that will create more unplanned work for the next time.

Hope that helps?