We have been using Sandglaz to manage Sandglaz’s backlog since pretty much the beginning. It has given us one extra input to prioritization; when we know we need a certain capability out of Sandglaz, we figure probably our users do too, so we prioritize it accordingly.

I have long been fond of iterative development, a software development practice that advocates delivering early and often to the customer, typically every one to four weeks. Prioritizing a product backlog is one big beast that has been elaborated on extensively in the software industry. In this post I will explain how we use Sandglaz to prioritize and keep track of the “stuff” we need to do, and how we eliminate the weaknesses of other prioritization methods.

Before I indulge in the details, I’m going to go back in time and tell a story.

“If everything is high priority then nothing is”

I once worked in a place where issues tracked can be assigned one of three priorities high, medium or low. In practice, 99% of the issues were assigned high and 1% were assigned medium, none were low. And what this meant to the developers was high = do it, medium = ignore it. Almost everyone who worked there agreed this is not an efficient prioritization system, yet fixing it proved to be too hard. They used this system for several years!

One of the problems here is that high or medium don’t really mean anything unless you define them. Unfortunately, the usual attempts at such definitions is a categorical description e.g. high is a feature that has major impact on the customer. In reality this only shifts the ambiguity by one layer, because terms like major and minor are just as subjective as high and medium.

Our suggestion here is to drop this method altogether, and alternatively think of your backlog in terms of your iterations. So instead of asking yourself is this high or low priority, ask yourself is this something we want to do in this release [1], or is it a possibility for the next release. This removes the ambiguity entirely, and it also forces you to restrict the number of immediate tasks.

Three more axioms to add to this:
1. Your product backlog needs to be looked at and re-prioritized regularly [2].
2. Tasks that need to be done sooner, need to be more granular. For example if you were going to add a blog to your site in some later iteration. You jot down add a blog to site, but if you were going to do it in this iteration, then you will need to make several tasks for it which will include things like build a blog post model, build a blog comments model, build the interface, build permissions...etc [3].
3. Estimating accurately how much work can be done in a given time frame is nearly impossible [4].

Using a 2x3 grid, place the tasks that you plan to do in this release in the first column, the ones that are good candidates for next release in the second column, and the rest in the third column. And since we know from axiom 3 that we can’t accurately estimate how much work can be done in an iteration, you will further separate the tasks in each column into two rows. In the top row put tasks that are a release blocker, and in the second row those that won’t hold release if they did not get done. Release-blocker vs not-release-blocker is a clear way to define important and unimportant. This grid structure also provides you with a way to categorize long term priorities.

The above grid is an example of how some tasks could be prioritized in Sandglaz’s backlog [5]. In the Important & Now cell, we have tasks required to implement grid sharing. The tasks are more granular than those under Important & Next, since they need to be worked on now.

In the Unimportant & Now cell we have “Add RSS feed icon to site footer”. This is an example of a task planned for this iteration, however if unforeseen problems arise and it doesn’t get done, it will not block release.

In the Important & Later cell, we have the task “create Sign up page”. This is an example of keeping track of a long term importance. A sign up page is a necessity for a web-based product, however you don’t want to implement it until you are out of private beta. Being restricted with the choices of high, medium or low priority wouldn’t have made much sense in this case.
It is also worth noting that this task is not yet fine-grained, because it’s not being tackled today. For example, decisions like whether opening up the sign-up page should include email confirmation or not is left until the task is moved to the Next or Now columns

Back to Axiom 1, don’t forget to prioritize and re-prioritize your backlog regularly. In addition you will need to visit it between iterations to move tasks to the left while increasing task granularity.

If you are a small team, a start-up or working alone, this is a great lightweight way to manage your backlog. One thing I love about it is that it allows you to see the big picture all the time in one page, while easily pinpointing the priorities.

I will also add that for this to work, or really for any iterative process to work, you will need to keep your code base production quality at all times and well unit tested.


[1] For the purposes of this post the terms release and iteration are interchangeable, a release goes out to the customer at the end of every iteration. In some companies several iterations plus regression testing leads to a single release and a single deployment to the customer. I personally think this is a flawed way for a company to pretend that they adopted an agile process, when in reality the lack of production quality code base and thorough unit tests prevents them from stable and regular releases to the customer. This method also defeats a key advantage of agile: responsiveness to changing customer requirements.
[2] This is important to be responsive to changing requirements.
[3] Often referred to as breaking down user stories.
[4] Most agile methodologies advocates varying either time or scope of iterations.
[5] This is just an example and not a true representation of our backlog. The example tasks used are those of features already implemented in Sandglaz.