Getting started with a Backlog. The Mindset.

I was going to just set up my backlog, and started typing away what a backlog is. Turns out this is my first blog post. Enjoy!

I got to know the term “backlog” when we started using Scrum almost 10 years ago. Basically, it’s a list of features that serve user stories: things a user will eventually be able to do with what you build, like making a pdf of a document.

The “old” Way

Now, in “robust” project management, you would complete that list of features at the beginning of the project, call it the “specification” or “requirement set” and start working that list off, until your done; you deliver the “product” to your customer, she is amazed how well you were able to foresay her needs… (see it coming?) – or you finally realize that what you had specified months or even years back no longer really fits the current needs, investments are sunk, customers are waiting, management turns impatient.

Been there?

The Mindset

Now, agile is often – and at first! – perceived by many as “let’s just get started without an idea what we want to do”.

I couldn’t disagree more.

In my experience, it’s primarily a result of accepting that we can’t really foresay the future, but we need to move forward anyway – and it’s a great way of risk and change management. It probably takes more discipline than the well known “robust” approaches. You really need to stick to your roles and methods to make it work. But if you do, it can truly be amazing! Promise.

So, how can we assure that the investment we make results in the best possible value for the customer?

Short Intervals and Retrospectives

The answer lies in taking small steps and reflecting on them once completed in short intervals (“sprints” and “retrospectives” in Scrum). That means: define user stories (in plain words what a user will do) and make that initial list of features to make that happen.

Then sort these features by customer value – BUT only implement the first few, let’s say two weeks worth of work. Then, check if they do what you want them to do. If yes, good. If not, change or discard them. Discard? Yes, because maybe by now, customers needs have changed (she no longer needs that pdf).

Then reflect as a team how you performed and commit on necessary measures to improve.

Change Management

Before you work off the next items on your backlog (that list of features), add new features to it as you learned from the current world, and delete those that are obsolete by now. Then sort that list again by customer value and set to work for another 2 weeks or so.

The largest project I managed, had a budget of over 8 million, a feature set of almost 700. At the end of the project we haven’t implemented half of the original 700. Or, in other words, we’ve spent about 4 million on features and changes that we didn’t foresee at the beginning. Or, in even other words, we didn’t sink those 4 million. Cute, isn’t it?

Radical Management and more …

There’s some great resources on agile principles for example from the Scrum Alliance, even Wikipedia will get you started, or read “The Manager’s Guide to Radical Management” by Stephen Denning. A great book to understand why the new economy has created 20 million jobs in the US versus none by the old economy.

If you feel like throwing out the net farther, try googling for the “VUCA world”. VUCA: volatility, uncertainty, complexity and ambiguity.

Applied to this Blog

Now, let me get started with a super-easy adaptation of a backlog for my blog-posts-to-come.

Experience has Economic Value. Bubble Gum.