Prioritization process

There are so many things we want to accomplish. How do we prioritize these properly? In any teams’ backlog you will see stories, epics, customer bugs, and tasks. The type of work that we prioritize includes security fixes, bugs, features, UX improvements and technical debt.

Work is prioritized based on its ability to keep the product functioning at a high-quality production level, to help us fulfill our strategies and by demand from our communities and market. New features are prioritized based on how they help support company strategies and product goals. A high level principle that drives priortization is the value of the feature over the cost to develop the feature. One way that we try to measure this is through the RICE model. RICE stands for Reach, Impact, Confidence and Effort. A feature that would improve the product for a large volume of our end-users, would make a difference everyday to how they work and is fairly low risk and effort to add is likely prioritized over one that was very risky and did not make a difference to a large volume of users.

When something is not on the roadmap and is important to our community, we rely on feedback to know if we should reconsider prioritizing it. We value community input on our open source offering equally to feedback from our largest paying enterprise customers. Since our roadmapping process is agile, we often reconsider features based on new information for future releases.

Typically, we lock in on prioritization for a quarter’s worth of time. This allows our teams to focus on work for that quarter without major changes which are disruptive to the development flow. The next quarter’s work is usually queued, however there is some flexibility to changes prior to beginning development. Work planned for more than two quarters in the future is subject to changes and reprioritization.