Introduction
This release focuses on several usability improvements reported by our customers recently. Mostly this concerns the asynchronous voting and the summary box.
New features
After a pause for new features connected to mostly bug-fixing and support requests, we’re back on the track with the backlog of feature requests.
Asynchronous voting improvements
The asynchronous voting was a bit awkward as it didn’t show the current voting progress. It was difficult to understand when the voting has completed and it is time to collect the votes or ask for colleagues to complete the voting. Now the progress is visible.
The following progress is displayed:
- Overall progress for the session
- Progress for each team member who has voted at least once
- Progress for each planned story
The circular progress bar on the left is the overall progress and is the average of the completion percentage of all stories.
The progress for each team member is displayed in a row above the stories. If someone hasn’t voted for all stories, you could touch-base with the colleague to ask to vote for all stories
The progress for each story is displayed as a badge on the donut-chart icon at the right of the story. For example. if it shows 75% then 3 out of 4 team members voted for the story.
Note: The asynchronous voting has the following use case scenarios:
- All team members vote in advance (through the voicemail buttons on the right of each story), the scrum master collects/adjusts the votes
- Part of the team members vote in advance (through the voicemail buttons on the right of each story), the scrum master and the rest of the team members vote in real-time collaboratively discussing all votes (including the ones given in advance)
Similar tickets
This feature is available for Jira users only. The feature allows the users to see all tickets from the project to which the ticket belongs to that have a similar estimate.
There are 3 parameters that can be adjusted to better find similar tickets. First is the actual JQL the will be executed when you click on the ‘Similar tickets’ tab in the summary box. The JQL is a template and the {project} will be replaced with the current ticket’s project, the {field} will be replaced with the name of the field (Story Points, Story point estimate, timeoriginalestimate, etc.) and finally the {estimate_lower} and {estimate_upper} will be replaced with estimate*(1-tolerance/100.0) and estimate*(1+tolerance/100.0) respectively.
Next is the tolerance in percentage to indicate in what range similar tickets will be sought.
Finally the number of results returned can be set. This limits the number of similar tickets to avoid bloated results and focus only on the top-ranked results. If you don’t want sorting by rank or use more complex JQL queries, you can adjust it in the settings page (Integrations/Jira).
The similar tickets tab is a new one and appears only to non-external Jira users at the right of the summary tab. It shows the JQL query executed and the results.
If the JQL query was not specified correctly (has syntax errors for example), an error box will displayed with the details on the error. You can use the ordinary Jira advanced search for tuning the JQL before pasting it into the room settings.
The similarity of the estimate is calculated as a deviation to the current estimate. For example, when the tolerance is 0 and the estimate is 3, only stories from the ticket’s project that have estimate 3 will be displayed. If the tolerance is 50% then stories with 2 and 3 story points will be displayed.
The number of stories displayed in the similar stories tab is also controlled from the settings page inside Integrations/Jira tab.
Happy voting!
All those nice features (and fixed bugs) have been completed thanks to our users – they have requested and we have implemented them. Please help Scrumpy Planning Poker become even more convenient for you by submitting a feature request/bug to our Feature Requests page or up-vote an existing feature that you find useful. Thank you!