New: GitHub Integration for Sprint Poker
Parabol was built completely in the open using GitHub. Every new idea starts as a discussion. We pick the most compelling ideas and turn them into issues, where they’re prioritized and slated for the sprint. When done well, it’s as smooth as an assembly line.
The magic, of course, lives in how to prioritize the issues. Some teams estimate how long each issue will take. Other teams go a step further and estimate how much value an issue will provide towards reaching a certain objective. Some even mix these two values using what’s called “Weighted Shortest Job First” so they can get the best bang for their buck. With our latest GitHub Integration, we’ve made this easy for everyone.
Today, GitHub doesn’t offer a “Story point” field like Jira does. Instead, GitHub offers custom labels to use for filtering. For example, popular GitHub repositories will use the P-scale to rank bugs based on severity by creating a custom label for each.
With Parabol’s latest GitHub integration, you can select the issues you want to prioritize, discuss their size and value with your team, vote, and push the estimate to GitHub all in one smooth motion.
It begins in the Scope phase. In a single click you can integrate with GitHub.
Once integrated, we’ll show you the most recent GitHub issues that you’ve been working on. You can further filter the issues by a particular repository by using the dropdown filter menu. If you prefer a more advanced filter, such as by label, milestone, or body content, Parabol supports the entire GitHub search syntax. We’ll also save your most frequently used search queries so you won’t have to remember them.
After selecting the issues to estimate, it’s off to the poker table! This is where team members can discuss the issue. Parabol uniquely supports both synchronous and asynchronous meeting types so it works with remote teams of any size. Some teams even break apart the Scope and Estimate phases into separate meetings where the Product Owners meet to discuss scope and the Engineering team meetings to estimate how long it will take.
Commonly, technical product managers will participate in the estimation while non-technical managers will sit out by clicking “I don’t vote” in the upper right. How your team chooses to estimate the issues is up to you! To create Sprint Poker, Parabol worked closely with some of the most successful teams around the world. We give you the tools and best practices to guarantee that the meeting runs smoothly, there are no wrong answers here.
After the team has placed their bets on how long the issue will take, it’s up to the facilitator to decide what to do with that information. If the estimate is too high, that is usually a sign that the issue should be broken apart into two or more issues. If the range of bets is too wide, then it is a sure signal that the acceptance criteria is too vague and a discussion should be had to achieve consensus. If both the score and variance is low, then the estimate is ready to push to GitHub!
Pushing the estimate to GitHub requires a one-time setup on how you’d like the label to look. Simply type in the name of the label and replace the score with the placeholder {{#}}. Once complete, Parabol will take care of the rest. Behind the scenes, Parabol will create a new label if it doesn’t already exist. If you change the estimate, Parabol will remove the old label and apply the new one. If you later change the estimate inside GitHub, Parabol will make a note of that to help suggest more accurate future estimates (coming soon– stay tuned ).
