Forecasting in SAFe Without Story Point Theater

SAFe (The Scaled Agile Framework) uses Story Points throughout the various levels as its estimation currency. This is covered in the “Story” article on the SAFe site, and it is a pretty standard practice in organizations scaling agile these days. If you dive a bit deeper into how this is done in SAFe, you will see that the story points used in SAFe are quite similar to an “Ideal Developer Day” — this helps the teams align to a common baseline and supports a rational economic ROI discussion at the level of Features and Capabilities that require effort from more than one team, or haven’t even been mapped to a specific team yet.

An alternative to using Story Points at the team level, interesting to look at especially as Kanban is becoming a first-class citizen of the SAFe world, is to use NoEstimates.

In essence this means not trying to estimate the size of the work — just slice work into a size that we can bite on and turn around quickly. To get a quick grasp of it, think of replacing your classic Fibonacci planning poker cards with a set of cards saying 1, TFB (Too Frighteningly Big), NFC (No Faintest Clue). This approach is rising in popularity among Kanban and ScrumBan practitioners. We’ve been looking at the “Iteration Planning” process for years, trying to address some of its wastes and tensions.

This NoEstimates-inspired approach to story estimation in PI Planning has a couple of benefits:

• It is faster, which comes in handy during PI Planning.
• It forces teams to slice into smaller stories, which is better.
• It is naturally easier to baseline and align multiple teams around the same definition. (A 1 here would be something like a 3 or 5 in the classic SAFe velocity calculation — a story that takes the team about 3 days to develop and 3 days to test.)

Iteration Planning becomes even easier. Just understand your velocity and how many stories you can fit. Minimal time is spent estimating.

There are a couple of challenges though. Forcing the team to split their whole Feature into small 1-size stories, including those that are only going to be pulled in later iterations in the PI, might be a waste of time.

Another challenge is how to make rational economic decisions at the Feature and Capability level, and even the Epic level, without estimates. NoEstimates die-hards say it doesn’t make sense to estimate even at this level, not just at the stories level. I’m not convinced.

What I typically do in cases where teams stop estimating story sizes is just use story counts as the currency at the higher levels. So instead of saying “this seems to be a 20 Story Points Feature”, we would say “this Feature seems to be something around 20 stories” — meaning we estimate it will map to about 20 stories when we eventually slice it. We don’t slice it to stories in order to estimate. We reach that estimation using a classic relative estimate approach like Planning Poker or the Team Estimation Game.

This is actually something that helps with the first challenge as well. Knowing that we’re dealing with a Feature that we think has about 20 stories, and that we identified 7 stories for the first iteration and 4 stories for the second, we might say there are around 9 stories more for the third iteration. Or, better, let’s look at the remaining chunk, compare that to our feature estimation scale, and see how many stories we think there are in there.

Of course, if we think there are dragons (a.k.a. dependencies) hidden in this remaining chunk, we should make the effort to slice it into smaller stories and work out the dependencies and scheduling with the other teams on the train.

I’ve done this with clients in the trenches. Based on this experience, I consider this alternative approach to estimation a legitimate alternative to Story Points estimation at the SAFe team level.