It’s always an interesting process, planning what should go into a new release. We all have a gazillion opinions of what’s the most important new next feature to include, we all have darlings, and it’s not always that we choose new features based on a rock hard business case, meaning – will it make it easier for new players to get started, will it make players stay longer, will help us speed up production moving forward, will it help generating revenue, etc.
So in order tomake the decision process a bit more unbiased, I invented a new ‘game’ which could help us prioritize features in a more impartial way, by quantifying value, cost and risk to all features.
A while ago I fell across a prioritization process called “First Things First” by a process consultant called Karl E. Wiegers, and I used this as a basis for the game – meaning that we’re using a variation of his matrix and calculations to base the prioritizations on. That being said, we don’t dictate what comes into the game based on this alone, but it gives us a sanity check on which features gives us most “bang for the bucks” and which features doesn’t.
But let me try to explain the process…
To begin with we collect feature ideas and requests from various sources; our design documents, the community (yup – that’s you out there!), Square Enix (our publisher) and the development team. And yes – this list quickly becomes very long, and we might not have all great ideas in the list, but we’ll have the most relevant ones (or at least we try to).
Now that we’ve gathered a feature-list it’s time to play the game…
In the Wiegers matrix we list all features, and add a value for ‘benefit’, ‘penalty’, ‘cost’ and ‘risk’ to them.
- Benefit means, how big a benefit will we have by adding this feature – we have actually subdivided this into various types of benefits (new users benefit, retention benefit, revenue benefit, etc…) , but to keep it simple, let’s just refer to it as one total ‘benefit’.
- Penalty means, how much will we suffer by not having this feature.
- Cost means, how much will it cost us in terms of manpower or actual money if we choose to outsource it.
- Risk means, how much uncertainty is there in making and implementing it, and is there a chance that it might make things worse.
But how do we determine how big the benefit is, how do we estimate the cost, etc… Well, this is where the game really begins…
Let the games begin!
We have only tried this one time so far (with a list of 80 features), but it actually went quite well, so we’ll definately return to this process for the next prioritization meeting:
Reto.Goonstah (Technical Producer), Reto.RedBjarne (Game Director) and myself (Producer) were each given four cards with the numbers 0, 1, 2, 3 on them. Reto.Lusa was ‘bookkeeper’ and presented one feature at the time having one of us describing the feature in details. When we all knew what the feature was all about we started playing.
Starting with ‘benefit’ (or rather one of the benefits) we each played one of the cards face down. When all cards were on the table we flipped the cards and looked at the numbers. If all numbers were the same we we noted down that number for that benefit and continued to the next. If the numbers were different, the one with the highest number argued why it was so high, and the one with the lowest number also argued why it was so low – and then we played/argued again until we all reached the same number. Playing a ’0′ in for instance benefit means that there is no benefit in implementing this feature, whereas a ’3′ means that the benefit os really huge.
And this continued for all features and all values for each feature – 6 hours later we were through all the 80 features and had values for all.
If you have worked with software development you might find this technique similar to “planning poker” in Scrum, and the benefits to playing “blindly” is that you’re not influenced by what others say when you give your estimate.
The End Game
Now that we have estimated benefits, penalty, cost and risk for all features we start calculating and weighting the features and values, so we end up with a prioritized list. Wiegers suggests prioritizing purely based on a cost/benefit calculation (taking risk and penalty into account), which we also do, but we find it important also to look at just the benefits, so we don’t always go for the “best value for the money” feature, but also look at “expensive” features that might give us a really great benefit in the long run.
So, this small game and process gives us a tool to help us decide which features we should put in the next releases. Next step is how to break down the features to actual tasks and hwo to execute them… But that’s a whole other story…