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. This 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 actually the story points used in SAFe are quite similar to “Ideal Developer Day” as this helps the teams align to a common baseline and support a rational economic ROI discussion at the level of Features/Capabilities that require effort from more than one team or haven’t even been mapped to a specific team yet.

A poker planning, or scrum poker session involves product owners or customers and editors. The session begins with each estimator holding a deck of value-based cards ranging in sequence. We recommend the following: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. Poker planning is a powerful tool to make faster and more accurate estimations. Most important of all, it is used to make the boring meetings fun again! This app can be used in scrum poker planning sessions anywhere. The planning poker party is about getting a big group of stories estimated and establishing that baseline. Fabrice Aimetti on October 1, 2009 at 9:59 am said: Hi James, your initial article “Planning Poker or How to avoid analysis paralysis while release planning” is a reference.

An alternative to using Story Points at the team level that is 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/ScrumBan practitioners – We’ve been looking at the “Iteration Planning” process for years trying to address some of its wastes/tensions.

This “No Estimates” 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/align multiple teams around the same definition. (BTW 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/Capability and even Epic level without estimates. #NoEstimates die-hards say it doesn’t make sense to estimate even at this level, not just 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 / 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 something like there are around 9 stories more for the third iteration or even better – let’s look at the remaining chunk and compare that to our feature estimation scale and see how many stories we think there are 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/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.

This blog post was originally posted on Yuval’s personal blog back in 2016.

Planning Poker relies on relative estimating, in which the item being estimated is compared to one or more previously estimated items. It is the ratio between items that is important. An item estimated as 10 units of work (generally, story points) is estimated to take twice as long to complete as an item estimated as five units of work.

An advantage to relative estimating is that it becomes easier to do as a team estimates more items.

Estimating a new item becomes a matter of looking at the previously estimated items and finding something requiring a similar amount of work. This is easier to do when the team has already estimated 100 items than when they’ve only estimated 10.

But, relative estimating like with Planning Poker suffers from a bootstrapping problem: How does a team select the initial estimates to which they’ll compare?

My recommendation is that when a team first starts playing Planning Poker, team members identify two values that will establish their baseline. They do this without playing Planning Poker. They do it just through discussion. After the baseline is established, team members can use Planning Poker to estimate additional items.

Ideally, the team is able to identify both a two-point story and a five-point story. There is evidence that humans estimate most reliably when sticking within one order of magnitude.

Identifying a two-point product backlog item and a five-point item does a good job of spanning this order of magnitude. Many other items can then be more reliably compared against the two and the five.

If finding a two and a five proves difficult, look instead for a two and an eight, or a three and an eight. Anything that spans the one to 10 range where we’re good estimators will work.

Avoid Starting with a One-Point Story

Planning Poker Baseline Games

I like to avoid starting with a one-point story. It doesn’t leave room for anything smaller without resorting to fractions, and those are harder to work with later.

Additionally, comparing all subsequent stories to a one-point story is difficult. Saying one product backlog item will take two or three times longer than another seems intuitively easier and more accurate than saying something will take 10 times longer.

I made this point in my 2005 “Agile Estimating and Planning” book (now also a video course). In 2013, it was confirmed by Magne Jørgensen of the Simula Research Lab. Jørgensen, a highly respected researcher, conducted experiments involving 62 developers. He found that “using a small user story as the reference tends to make the stories to be estimated too small due to an assimilation effect.”

Why Use Two Values for a Baseline?

Establishing a baseline of two values allows for even the first stories being estimated to be compared to two other items. This is known as triangulating and helps achieve more consistent estimates.

If a team has established a baseline with two- and five-point stories, team members can validate a three-point estimate by thinking whether it will take longer than the two and less time than the five.

Citing again the research of Jørgensen, there is evidence that the direction of comparison matters. Comparing the item being estimated to one story that will take less time to develop and another that will take longer is likely to improve the estimate.

Don’t Establish a New Baseline Every Project

Some teams establish a new baselin