The Best Way of Estimating Your Product Backlog Effectively and Quickly

Before we get to the details, we’d like to first guide you into a proper mindset and get your focus on the essence of an estimating process.

HOW TO ENTER A PROPER MINDSET WHEN ESTIMATING

#1 Ask proper questions

When estimating, the question which we ask ourselves is “how big this item is?”, instead of wondering “how much time it will take?”. Time-related values are hard to predict and they come with a high risk of being incorrect. We use Story Points (SP) instead and, by grouping similarly sized features, we assign the values to them.

#2 Don’t care about the raw numbers

What we keep our focus on are the relative values of estimates between the PBIs. An item estimated to have 2 Story Points is twice as big as an item estimated to have 1 Story Point. An 8 SP user story is almost 3 times bigger than a 3 SP task.

#3 Gain value from keeping the focus on references

So, during the estimation process, we simply look for the reference points, and then we assign Product Backlog items their relative value. The advantage of this approach is that everyone will easily agree that implementing a static logo is a smaller task than having it animated with rainbows flying around it, no matter if we had experience with it in the past.

Secondly, we might sometimes make mistakes when grouping similar features but, in the end, we will gain on some and lose on others. Furthermore, the Development Team’s tempo on burning the Story Points after a couple of sprints will give us a rather reliable value, which can be used to plan the scope of the next iterations.

TEAM ESTIMATION GAME – THE BEST WAY TO FIND REFERENCES QUICKLY

In the past, we have tried different methods to have our Product Backlog estimated, including “Planning poker”. When we tried the Team Estimation Game out, we were really amazed how helpful it is, quickly find strong references between stories and tasks.

Check out the rules below and try it out for yourself.

Rules of the Game

• used during Sprint Refinement meetings
• the Development Team needs to have at least a basic understanding of the Product Backlog and study the Product Backlog individually before the refinement sessions
• based on a stack of story cards, ordered accordingly to Product Backlog priorities (the top priority card goes on the top of the deck)

Part #1 – Comparing

• someone starts the game by taking the top story from the deck, reading it aloud and placing it in the middle of the wall/table
• another person picks the next story off the top of the deck and reads it to everyone, then decides if it’s smaller or bigger than the story placed on the wall/table:
  • if it’s smaller, it gets placed on the left
  • if it’s bigger, it gets placed on the right
  • if it’s around the same, then it should be placed below the already placed story card (forming a column)

• another person in the queue can:
  • either take another story card from the deck and place it on the wall/table
  • move a single story card already placed on the wall/table together with a comment explaining this move
• the team continues to take turns placing stories until all cards from the deck are placed
• now, instead of placing new stories, the team is fine-tuning the order by moving them one at a time with a few words of explanation
• the game continues until everyone says “pass” (which means that we are happy about the order) – this is the stage when the team has their stories ordered left to right, smallest to largest

Part #2 – Estimating

• for the next step, the team places Story Points estimates on a place on the wall/table above the specific columns, starting with the smallest estimate (using the Fibonacci sequence)

• the same is done for all the next estimate sizes until all cards have their SP values
  at the very end there is 5-10 minutes final check phase – in case of doubt, an index card can be discussed shortly for the last time and may be re-positioned
• when estimating stories again with the Team Estimation Game during the next refinement sessions, it’s best to place on the wall/table stories estimated before (for example with 1, 5, and 13 SP values assigned) and compare new stories to those

WRAP UP

And… well, that’s it! We hope that we gave you an idea of how easy, fast, and fun the Product Backlog estimations with Team Estimation Game can be. But, even more importantly, we would certainly be happy if you decide to follow the suggested mindset and explore the value of relative estimates with strong and clear reference points yourself.

The last pro-tip worth mentioning, which we believe is a key component of a successful estimation process, is to remember that the actual discussion around a feature, especially with the Product Owner who can best express the business value, is worth millions of times more than the actual estimate value. Get our Free Guide for Product Owners – Drive your Product to Success.

So, don’t be afraid to ask questions, make sure that each PBI is super clear, and get really familiar with the expectations for the product you are about to build.

In my next blogpost, you will read about the Team Estimation Game for remote teams. Stay tuned! 

Related posts