LIfe without a backlog
Backlog is not part of our process anymore. Our process starts with analysis and ends with done. This is a deliberate choice, a choice we always have to remember we made because it is so easy to go back to dumping every single idea into a card and accumulate an enormous backlog that then has to be prioritised, estimated, trimmed. We also operate without a bug list, at least so far. I have already blogged about the advantages of that.
How do we plan then ?
We use a roadmap. The shorter the horizon, the more fine grained. I use a template from enthiosys. We record functional and architectural goals on it. We record events (demos, vacations, code freezes). We also record our target markets. The roadmap has a lot of white space. Not all categories have something at every time horizons. What this means however is that we implicitly estimate when features will be completed from a very high level. This in turn gives us a lot of room to adjust what we actually deliver using dimensional planning. When we need to decide what we do next we use our roadmap and we usually make the decision in a few seconds. That is when the analysis work starts that will cut a workable story. What does not fit in the story is not recorded but will probably resurface on the next round, informed by what we learned while playing the previous story.
What about the product vision ?
We have from the beginning created a set of documents that we keep current. One is a contextual diagram that shows how this kind of product generally fits in our clients’ processes. Another one shows how it fits in the software the company produces (which is a much larger thing). Finally we have a diagram that outlines the end state of our product with a broad view of the functions we want to build. The roadmap takes over from this high level vision with a time horizon of a year or so. In addition we have an architectural context and a domain model established before we start on a functional area.
What’s the catch ?
There are several things that make this possible. First we are a very small team (one developer, one BA/QA). We both have a significant expertise in the domain and in that specific product. This process can certainly scale beyond that size but I am not sure how much. Second, we were hired to build that product and therefore we have a lot more control over how we manage things. We also do not have existing clients or contractually agreed scope to deal with.
What are the advantages ?
Primarily we removed many of the things that generate pain in a software development process. No estimates means no actuals (more on this). No backlog makes it very cheap to rearrange our priorities. No detailed long term plan means we do not have the temptation to adhere to it. Instead we reshape the plan constantly to reflect the new information we acquire. Finally all of this provides us with the material to efficiently communicate with our prospects and clients. We show enough structure that they easily understand where we are going and at the same time we have enough flexibility to incorporate their feedback in our plan. And the same thing applies to communication with upper management.
That is a short presentation of how we (so far happily) operate. What is your experience like ? Have you tried similar things ? Or other things ? How did they work out ?
