Skip to main content

Does/can bucket system replace planning poker?

Last post 06:15 pm September 17, 2019 by Ian Mitchell
3 replies
04:09 pm September 17, 2019

Is it possible to just use bucket theory to size (story point) a whole bunch of stories, rather than using planning poker?

Bucket system seems to work much nicer than planning poker - planning poker you're sizing a few stories at a time, making it difficulty to gauge the relative size. With bucket system, you can grab a whole bunch of stories (maybe for an entire release?) and size them all in one go.

When sizing the next batch/release of stories, I'm thinking its a good idea to have "reference stories", e.g. keep a representative 1 and a representative 20, so that the team can again, size with relation to the previous batch of stories.


04:31 pm September 17, 2019

Yes - planning poker is not a required exercise in order to estimate items in the Product Backlog. 

That being said, it can be valuable in that it gives the team a way to include every member in estimating, helps create a clear understanding of what needs done, helps the team have some productive conflict, and allows for some fun in the process. I'd wouldn't be surprised to see some teams to grow out of poker and look for other more efficient ways of estimating. 

Does bucket planning still allow the team to collectively understand what needs done to complete a given story? 


05:26 pm September 17, 2019

I'm not familiar with the Bucket system so not sure if I can respond on it's applicability.  But I will say that Planning Poker is not part of Scrum.  It is something that a lot of teams have found helpful but there are many teams that have found it unhelpful.  The Scrum Guide only mentions estimates, not story points.  How ever your team finds it beneficial to do estimates and can become better at providing such estimates seems appropriate to me.  I once lead an exercise in estimating using fruit.  Different sized, different textures, different ways to use the fruit could all be considered in estimation.  I see no reason buckets can't be useful.  

When sizing the next batch/release of stories, I'm thinking its a good idea to have "reference stories", e.g. keep a representative 1 and a representative 20, so that the team can again, size with relation to the previous batch of stories.

Would these reference stories be using their original estimate or are you suggesting putting actual values after the fact based on the work done? And will these reference stories change over time as the team and product matures?Wouldn't the discovery encountered while doing the reference story influence the estimation of a future story that could be considered similar?  And if so, see the first question in this paragraph. 

I recommend not revisiting and changing an estimate to an actual for this purpose because that is a slippery slope to updating all the stories in your sprints to ensure that you get "credit" for all of the work actually done and story points become a measurement of success instead of using the value produced as the measurements. Estimates are guesses based on what you know at the time of making the estimate.  The beauty of Planning Poker is that it suggests you do the activity relative to what you know not based on something you have estimated in the past. I feel that each Product Backlog Item should stand alone and as such should be handled alone and not as a larger bundle.  The Backlog Ordering is done based on the definition of each story. Even related stories are not always ordered together. 

So, while buckets could be used as a sizing mechanism, such as t-shirt sizing, I don't advocate trying to lump many items together in general terms.  Inspect and adapt each item independent of each other. I have seen too many problems arise because "these are all the same" is used which leads to much less discussion, i.e. transparency, on the individual items.


06:15 pm September 17, 2019

Bucket system seems to work much nicer than planning poker

Is that the experience of your team? Has it significantly improved their ability to forecast how much work they can take on and deliver?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.