Estimate the complexity of your software with planning poker
At the startup that I joined recently, Hstry.org, we are currently building a product for the education market. Our goal with this product is to make the process of learning history more interesting and fun for students. Ultimately, we hope that our method will have a positive result on the outcome of learning. To test our product, we are running a pilot at a summer school in July and so we want to have a prototype ready by then. A few weeks ago me and my CEO attended a workshop about agile development and we thought that building this prototype would be a good opportunity to apply some agile techniques in practice. To estimate the development complexity of the features of our product, we used the “planning poker” technique and I have to say that it was a very valuable exercise.
As you probably know, agile development is the way to go in software development. It finds its roots in the 70’s when people realized that an frighteningly important number of IT projects either fail or go way beyond their budget. The agile movement came as a reaction against the now obsolete waterfall process. The agile methodology is more of a philosophy than a concrete set of techniques (the Agile Manifesto is a very interesting read) but there exist several “implementations” of that use the agile principles (Extreme Programming and Scrum are two popular ones). During its existence, the agile movement has not only shown that it’s nice in theory but it also has proven that it actually works great in practice. Not so long ago I read about how the agile principles are at the core of the whole product development process at Spotify and it was a true eye opener.
Know what you are building
For our product, we had already identified a list of features that it should have and we had even paid a designer to create some mock-ups to show to investors. So we had a fairly good idea of how the product should look and how it should behave. The question was now how to guide the development process given the limited time-frame (a bit less than one month and a half). It was highly improbable that we would be able to implement all the features we had envisioned so we had to decide on an order in which to implement them.
The first thing we did was to write down all the features on post-its, one feature per piece of paper. Then we considered each one and attributed it a business value. The business value measures how important the feature is for the product, looking from a business perspective. In our case, it was the usefulness of the feature for the student that is using our product to learn about history. A must-have obviously has a higher business value than a nice-to-have. During the process, if we felt it was too hard to estimate a value because the feature was too vague, we tried to split the feature into sub-features and estimate the business value of the sub-features instead. So in the end we had a list of features, sorted from top to bottom according to their business value. This was to be the order in which we would build the product.
Estimate thy complexity with planning poker
The next thing to do was to estimate the difficulty of implementing a feature and this is where we used planning poker. I sat down together with my CEO, both in front of the list of post-its with features, and each of us had a deck of “planning poker” cards in his hands. Each deck has cards that are numbered 0, 1/2, 1, 2, 3, 5, 8, …, 100, have a ? (question mark) or “infinity”. The numbers grow as a Fibonacci sequence and this is to reflect the inherent uncertainty in estimating larger items. A higher number obviously means a higher complexity and the goal is to attribute a number to each feature to estimate its difficulty. The question mark means that there are too many uncertainties in order to make an estimate, for instance if the feature requires using a technology that you don’t have experience with and you are therefore not sure how difficult it is to implement a certain thing. In that case, you go to your laptop, do some research about your problem and come back to attribute a number to the feature. The infinity means that the feature is way too complex and it indicates that it has to be split up into sub-features, whose complexities are then to be estimated separately.
The procedure we used was as follows. First, we picked one specific feature and we gave it a complexity of 5. This feature is to be the reference for the subsequent estimates; the complexity of the other features will be relative to the complexity of this feature. Then, we went through each feature. For each one, both of us put the card with the complexity that we think it should have, face down on the feature. It is important that no participant sees the card of the other participants so that our decision is not influenced by others. Then, we turned the cards face-up and if the numbers were different, we discussed. This was followed by another estimate, eventually another discussion, until we both agreed on a complexity.
A valuable exercise to anticipate on problems
The discussion that follows when there is a disagreement is the whole point of planning poker. In the end, we felt going through this process was very beneficial because it forced us to consider issues that would normally only show up later. For instance, we often had a different idea of what a feature comprised because we both had a different vision in our mind of certain details of the product. By having these discussions now, we can anticipate on confusions later on.
This is also one of the ideas underlying the agile process: it recognizes that confusion and problems will arise during the development of a software product and the agile principles serve to detect them and solve them early rather than later!