Very similar to planning poker, value poker is a “game” where each participant vote by showing a number out of a deck of cards. Establish a baseline for the value estimates by using a well. As someone else mentioned, planning poker is a great aid when using this method because it will help identify stories that need further refinement (if there is a discrepancy between votes, it means there is uncertainty in the requirements).

Planning poker decks Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. 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.

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.

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.

Planning Poker Baseline Games

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.

Planning Poker Baseline Template

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.

Planning Poker Baseline Rules

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