Every software project has three phases of its life, build, maintain, and sunset. A project can go through many build and maintain cycles through its life, but if you’re neither building nor maintaining, then you are sunsetting (which is a nice way to say “killing) your product.
The regular build/maintain cycles of a project are relatively easy to figure out, you listen to feedback, find out what features most users want, make sure it fits into your business model, and build the things that are needed to make your business thrive.
In the beginning though, you’re working off of assumptions. Sure, you base your product on user feedback and user interviews, but most people don’t know what they don’t know, so it’s all a shot in the dark.
“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 Manage Comics, we knew there was a ton of things to do, but because we’re such a small team, we would need to aggressively prioritize. Our friends at Code Elves are incredibly great to work with, and they work within our budget, but we have to balance how much we’re spending on coding with how much we’re bringing in to the business.
Manage Comics has always been bootstrapped, and it has made enough money to cover its monthly expenses since day one. I’ve never paid myself for work, and NorthIQ has bankrolled the majority of the updates to the system.
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 Manage Comics Roadmap“.
We run Manage Comics 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 item 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 items on blue Post-It Notes, and the development ones on green Post-It Notes.
As is usually the case, there are 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 we put a line of star post-it notes. These stars were 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
In agile, Value is how valuable to the overall project an individual item is. This is a hard thing to decide if you have no baseline, so what we do is just randomly grab an item and assign it a middle number (8 is in the middle of our sequence).
In this case, I blindly grabbed one item, and put it on the wall at the number “8”, creating our baseline item, and it’s the middle of the road. In this case it was “Better Error Pages” just by pure luck.
We then took all of the remaining items, and decided if they were more, or less valuable than better error pages. More valuable got a higher number, less valuable got a lower number.
Play Poker for Effort
The next stage was effort.
In Agile, a point is a unit of effort…not related to time. We have been using agile long enough that we kind of break it down into things we’ve done in the past, and we’ve got some rough benchmarks for what a point is worth.
For our purposes we figured it out like this:
1 – Tiny item (something like configuration)
8 – An average item (something that is pretty discreet and wouldn’t require us to test the whole system to implement)
20 – A very big item (something that will require a bunch of different testing)
100 – Infinite – too big to estimate, needs to be broken down into smaller chunks.
Now our sequence has 1, 2, 3, 5, 8, 10, 20, 30, 100. Numbers like 2, 3, and 5 are something between a 1 and an 8. 10 is between an 8 and a 20, and 30 is somewhere between a 20 and a 100. In truth, if something hits a 30, it probably needs to be broken down a little more.
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 item 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 item.
Calculating ROI
We know how valuable an item is, and how much effort it will take, the question is, what should we work on first? To figure this out, we create a return-on-investment calculation, and apply a little logic to it.
We took the value of an item and divided it by the effort of the item.
So a 100 value item that is slightly more than moderately difficult (10 points) has a ROI of 10.
A item with a value of 1 that is slightly more than moderately difficult (10 points) 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. If something would provide minimal value, and take a lot of effort, why waste time on it? These items were thrown directly in the garbage and deleted from our Basecamp never to be heard from again!
We ended up with 34 items that were prioritized and 8 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.
Doing this the first time took us the better part of four hours, but we ended up with a roadmap to the future!
We’ve used this to push out a number of releases, including a huge August release that we called the “V1.65” System Update.
That’s our process…how do you build products? Does it look anything like our process?
