Feature prioritization is always difficult to do, especially if there are 612 open issues when writing this answer. In the early days of Baserow, it was much easier because there were fewer issues, less community activity, fewer users, and no customers. This made it easy for me to keep an overview of which big features were needed most, which bugs were important, but also prioritizing some small features on the spot.
Since then, our team has grown, taking over responsibilities for me. Many people in the company speak with users, the active users have increased significantly, and there are many customers who want different things. The old system, of me keeping a lot of that information in my head just didn’t work anymore. We had more unanswered questions during our monthly planning meeting, and realized we needed to change things.
We always had a good idea of which big features we wanted to develop. While the issue list kept increasing, we needed a way to prioritize the big features, smaller changes and bug fixes as well.
To get a better overview, we wrote a script that synchronizes all GitLab issues with a table in Baserow. This gives us more flexibility in adding tasks that are not an issue, mixing in feature requests, and storing additional information like which customer has requested a feature.
We also came up with a scoring system where we score every issue, from one to six (higher is better), on adoption, revenue, strategic, dev effort, operational and risk. Next, we figured out how much each score must weight. Because we’re in an early stage and have limited development resources, we think that adoption and dev offer are more important than the rest. The Baserow formula looks like this:
(field('Benefit: Adoption')/6)(25) +
(field('Benefit: Revenue')/6)(15) +
(field('Benefit: Strategic')/6)(10) +
(field('Cost: Dev effort')/6)(25) +
(field('Cost: Operational')/6)(15) +
(field('Cost: Risk')/6)(10)
If we want to focus on a different metric, we can adjust the weights to fit our needs.
Because we want the community to be able to see this score as well, we’re synchronizing the score back into the weight column in GitLab. This allows everyone to see a prioritized list of features: Issues · Baserow / baserow · GitLab.
, I prefer to score for not more than an hour, but this is a personal preference. After the release, which happens roughly every 5 weeks, we have a planning meeting where we discuss new feature requests, sometimes even score them, and go over the highest scored issues. This can sometimes result in changing the score because we think issues are not scored correctly. Based on the ones that are scored highest, we decide what the priorities will be in the next week.