Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,457,003
Community Members
 
Community Events
176
Community Groups

Refund Vote Budget

I like the idea that users only get a certain number of votes and therefore have to really think about what feature/product ideas they're voting on; however, is there any way to refund those votes once an idea is delivered or archived?

I saw a similar question about "resetting" voting where the answer was just to create a new voting field. This is not an acceptable solution for an idea backlog that is a living document.

2 answers

Hi @adams.laborde , what @Bill Sheboy explained is what we tried to do here, where voting is a point in time activity, not an ongoing activity - that comes from a belief that prioritization should not be a crowdsourced activity, so voting is instead something we think PMs should use use to gather feedback in a time-boxed manner with a lot of guidance.

That being said, I think you could use the current feature for what you're trying to do, but only if you forgo the requirement that people can only allocate a specific budget amongst ideas. Basically: create a vote field, give people 10000 votes, add the field to a view. People can vote for any number of ideas, with up to 10 votes per idea. It's not ideal, but maybe takes you closer to what you're trying to do?

Your suggestion is an interesting one: people have 10 votes they can allocate to a set of ideas that are being considered for prioritization, and they get their vote back when the ideas move to a different state (accepted in the roadmap, delivered, other). We'll think about it when we revisit the voting feature. Thanks!

I made a mistake in the initial reply to state that prioritization should be time-boxed - I meant that we think (rightly or wrongly) that voting is an activity that is better used in a time-boxed manner, for a specific context/goal. I edited the reply. 

1 vote

Hi @adams.laborde 

This feature seems based around the prioritization method of "Vegas Voting" or "Dot Voting", where participants get a specific number of votes for a specific context (objective, timeframe, and set of items/ideas).  So re-claiming votes for completed items does not seem as valuable as either: 

  • no new votes are available until all selected items are completed or abandoned...which essentially leads to...
  • all votes are reset due to a new context (objective, timeframe, and set of items/ideas)

Perhaps you could explain your use case further.  Thanks!

Kind regards,
Bill

Yes, and...to my own answer  :^)

One possible use case where "resetting" or "reclaiming" votes can help is teams using Kanban practices during Queue Replenishment (i.e. an intake refinement practice):

  • teams have identified (through measurement) their capacity to complete work
  • so they periodically meet with stakeholders, stating something like "based on work we have just delivered, we have capacity to deliver 3 new things in the next week"
  • stakeholders collaborate to use economic-based decision making (or other priority practices) to select exactly 3 more things, in a just-in-time manner.  This eliminates the waste of reprioritizing or voting for things for which the team does not have capacity to deliver.

And so the rate of delivery (completed items) does make available capacity for more items (demand) to be done.  When demand regularly outpaces capacity, the team works with stakeholders on ways to improve efficiency, quality, and capacity.

Like Zach likes this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events