How to prioritise your IT projects and make decisions based on numbers
Introducing Mycroft Holmes (High-Optional, Logical, Multi-Evaluating Supervisor) aka Mike.
Shipping a new feature is just the beginning of the journey. Users will start to use it, bugs will definitely show up and minor tweaks will be requested.
Once you have a set of features running on production and new projects waiting for developers’ time certain decisions will have to be made. Should we focus on bug fixing? Should we improve already shipped feature? Or rather focus on a new shiny thing that your product manager has recently came up with? Your consumer support folks will put pressure on bug fixing while your project manager will probably want you to give This New Great Project a try.
Question, questions, questions. But, is there an answer?
Introducing Mycroft Holmes aka Mike
In one of our recent posts, Joanna described our team’s approach to prioritising work on legacy components:
As we couldn’t rely on qualitative marks of different stakeholders regarding the value of components, we started to rely entirely on the component statistic data in order to prioritise our work.
Metrics and features score
Mike has been build on top of this idea. It serves as both metrics gathering tool and a dashboard that you can visit to see how your features behave.
What kind of metrics do we collect? To name just a few:
- JIRA statistics regarding number of major and minor tickets
- feature usage statistics taken from Google Analytics: page views, events count
- statistics taken from MySQL database query
- access logs taken from Elasticsearch
Sum of metrics values gives a score for each feature that we use to prioritise the work. We can say that the higher the score the more important the feature is. By important we mean: it’s used by the users and bugs reported shows that it should get some developers time to fix them. Does it really make sense to fix bugs for barely used feature?
All metrics can be customised (you can specify JQL query or Google Analytics filters) and get various weights to tweak the score formula to match your needs. This tool is there to help you make the right decision based on numbers.
Dashboard
Mike’s dashboard gives you an overview of all features that it takes a look at. They are sorted by the score. Each widget shows metrics for each feature. When clicked a more detailed screen will show up.
Further more, each component can have a link to documentation and code repository. A Holly Grail is here — one place to find the documentation for all features you own.
Mike also keeps track of metrics and scores values. You can export components data and metrics to JSON and CSV file. Configuration of all metrics and features is kept in a single YAML file.
We’re open source!
Mike’s code is public, open source and free of charge. For your convenience we also provide up-to-date Docker image. As always, we’re open for suggestions, comments and pull requests.
What’s next?
Mike has been written in Python using Flask framework. For now metrics are stored in MySQL database. We plan to add more metrics and provide support for different kinds of storage and allow metrics to be pushed to Prometheus, so that you can set up alerting on features scores.
