“Am I building the right thing” is one of the hardest questions to answer. There always seems to be “one more feature” you could add, one more tweak you could make, or one more “Absolute Must Have” that you could do.
When we started working on BalanceDo, we knew there was a ton of things to do, but because we’re such a small team, we would need to aggressively prioritize. Because of that, we decided to use a favourite prioritization exercise of mine.
We use Basecamp to track all of the feature requests and feature enhancements that we want to work on. Everything from creating an internal dashboard to keep track of sign ups, to building a better onboarding process is in a project called “The BalanceDo Roadmap”.
We run BalanceDo using the Agile principle of “sprints”, we run two week sprints, and we try to release our new features regularly (often as soon as a feature is complete).
In the beginning…there were Post It Notes
The first part of the task was to take all of the features that we had, and write them out on Post-It Notes. I made all of the design type tasks on blue Post-It Notes, and the development ones on green Post-It Notes.
We immediately noticed was that we had way more green notes than blue notes, meaning that we were constrained by how many software things we would need to prioritize.
Along the side of the Post-It notes in the image above you’ll notice a line of star Post-Its. These are in a modified Fibonacci sequence. 1, 2, 3, 5, 8, 10, 20, 30, 100. This number has two different jobs at two different times. It represents value – how much we think the feature is worth, and we also use it to represent effort – how long it will take.
Putting a Number to Value
I blindly grabbed one task, and put it on the wall at the number “10”, creating our baseline task, and it’s the middle of the road. In this case it was “Referral Program” just by pure luck.
We then took all of the remaining tasks, and decided if they were more, or less valuable than a referral program. More valuable got a higher number, less valuable got a lower number.
Play Poker for Effort
The next stage was effort. For this, and since we are still getting our heads wrapped around how we are doing things, we broke a basic principle of Agile, and related points to time. In Agile, a point is a unit of effort…not related to time. That’s really hard to establish in the beginning, so since everyone understands time, we sometimes use that as a short hand.
For our purposes we figured it out like this:
- 1 – One hour
- 2 – Two hours
- 3 – Half a Day
- 5 – One Day
- 8 – A Day and a Half
- 10 – Half a Week
- 20 – One Week
- 30 – Two Weeks
- 100 – Infinite – too big to estimate
We then use a system called “planning poker” where everyone has poker cards representing the numbers, and we get to vote on how much effort we think it will take to get the task done. In some cases everyone will agree, in cases where there’s a disagreement the highest estimate and the lowest estimate talk it out (while everyone else must remain silent). We re-vote, and when the votes are unanimous, we move on to the next task.
We then took the value of a task and divided it by the effort of the task. So a 100 value task that would take half a week (10 points) has a ROI of 10. A task with a value of 1 that will take half a week has an ROI of .1.
We then map those all out on a board, and we decided anything with less than a .5 ROI would be thrown away (for now).
We ended up with 30 tasks that were prioritized and 10 tasks that were tossed away.
A quick view into a road map
Next, we looked at what we could get done in the next couple of weeks, and figured out which tasks absolutely needed to get out the door.
We divvied those up, and got to work.
This took us the better part of four hours, but we now know the next four months, and have set ourselves up on a roadmap to the future!
This has worked very well for us, it has let us figure out what we can do that will deliver the most value in the shortest amount of time, and has laid out a clear path for us.
I’d love to hear any other ideas, either below in our comments, or on Twitter @briangarside