What's the logic for "Vote" fields?

[Sarah Green]

When setting up a voting field, how exactly does the "Votes per user" logic work? Are these votes spread across ALL ideas? Are they limited to views?

[Tanguy Crusson · Accepted solution]

@Sarah Green think of it as a way to seek input: "If you had $10, how would you allocate it among the following ideas?". We found this to be a pretty effective way to get input from leadership or stakeholders. Voting for 10 ideas isn't the same as saying it's $6 for one idea, and then $1 for four other ideas.

The way this works is you create a field, add it to a view where you filter down the list of ideas, share it with people, and then discuss the results. 

If you want to seek input from different groups of people (e.g. sales, support which would vote for different things) or for the same group at different times (e.g. support in Q1, support in Q2) then you can create multiple Votes fields which you add to separate views. You can look at all the results in one view by adding multiple votes fields to a single view. 

E.g. 

• Support input - Q1
• Sales input - Q1
• Leadership input - Q1
• Total votes = formula adding these 3. 

[Sarah Green]

@Tanguy Crusson so is a user's votes view specific?

Let's say I have a vote field set up that has 5 votes per user. If there is an idea in one view and a user uses all 5 votes on that idea, would they have 5 votes to use on that same idea if it's in another view? Or once they use their 5 votes, they're done regardless of view?

[Tanguy Crusson]

It is not view specific, it a number of votes to spread across ideas. 

[Jack Verstappen]

Any thoughts on long term vs short term voting. At the moment (AFAIK) the number of votes allowed to an individual have a life-time value. Imagine that a company has a quarterly cycle, where some (voted) ideas have been implemented or have become outdated... it is up to the individual to remove prior votes in order to express the (evolving) preference. Some periodic reset feature would be helpful in this. 

[Tanguy Crusson]

Yep that's exactly why we recommend you create a new voting field for each new cycle @Jack Verstappen 👍 That way you can keep the history of who voted for what and why, and you can also reset it when you start a new cycle.

[Jack Verstappen]

While your approach works, I can't escape from thinking this thru my "Enterprise Scale" perspective. Most enterprise will have a quarterly cycle, where even the trend is moving towards 6-week cycle... which would mean 4-8 cycles/year. It will require the necessary discipline to keep those created vote fields with correct field naming in not getting lost. In addition to that it is up to individuals to pin/unpin the concerning vote field fitting to the "current" cycle. These created vote fields are available in JQL, but creating per cycle a vote field, could end up messy at enterprise Scale. Strangely enough I noticed that the vote fields can not be used in the filter and grouping feature within Jira Product Discovery (where I would expect that it would rely on jql)

I understand that your proposed solution fits best/easiest the strong items structure/architecture that Jira has benefitted so long. But personally I think it is constraining the user experience on certain functionality. "Cycles" would fit best to the "fixVersion" mechanism of Jira. It could benefit the user experience to only vote on elements that are assigned to a certain "fixVersion", represent a specific cycle. 

In the past year I have extensively worked with a customer to create enhancements to fit cyclic strategy delivery. In the multiple approaches visited, using the "fixVersion" ended up to fit best, as fixVersion are representing a period. 

Anyhow, just my 2 cents. 

[Gabriel Buck]

Do you mind telling me how you found the votes field or set it up? I do not see the available options. Is this a custom field?

[Tanguy Crusson]

Fields > create a field > field type: Votes

[Sarah Green]

@Gabriel Buck Team Votes Field (atlassian.com)