Do you need to have a product backlog? Does it have to conform with statements in the form of User Stories? I get a lot of these questions from all sorts of people that I’ve met or collaborated with throughout my career.

Lately, I’ve come to the conclusion that, no, you don’t need a Product Backlog – at least, not in the formal, certified Scrum sense. My thinking was especially influenced by my chat with Tom Gilb this past week to see if he would be willing to give a talk at the San Francisco Bay Area Business Agility Meetup. What I initially thought was going to be a 30-minute chat ended up being 2 hours. We started talking about all things Agile, what brought me into it, what he was doing back in the early days of Silicon Valley, what some of the things I’ve learned, encountered, and experienced during my career – basically a lot of fun – but really enlightening – stuff.

As I was recounting my journey, one of the things we had discussed was my first ever “agile” project that was hugely successful. This was back in 1998, and the term Agile was not yet in my lexicon. The manifest had not even been created at that point. However, I had been reading some novel ideas in the newsgroup alt.programming.tdd (who remembers Netnews, the precursor to the World Wide Web as we know it?), and decided to try things out with my team since we were faced with a daunting, brand new, never-before-done project.

One of the interesting things we did was to set up goals that we wanted to hit each week. In essence, we were doing one-week iterations. And the key driver for each week was to look at the biggest problems that were hurting or hampering us from delivering this new product to our customers (it was software for a very new piece of hardware that was taking the consumer market by storm).

Did we solve all of the problems each week? No. But we knew a little bit more each week and were able to code a little bit to move the product each week. Our first ever problem to solve, for example, was whether we could communicate with this new hardware when it was connected to our workstations (I was working at Sun Microsystems back then). When we saw the response from the device (our version of “Hello, world!”), we were ecstatic.

We did this each week – looking at problems, trying to solve them (even if partially), restating the problems if need be, adding new problems to our list, building things every night, and testing them the next day. We were seeing daily progress, and slowly, our product became real and usable. We released it internally, saying it was alpha. All of a sudden, I got flooded with requests from sales asking if they could get their hands on it (I was the team lead).

Inasmuch as I had initially said no to these requests, saying that the product wasn’t ready for prime time and that it still needed a bunch of other features to make it complete, I had sales pleading with me on phone calls. One had a $350,000 renewal on the line; another had a $150,000 potential customer ready to walk away from the deal without this new feature, for example (these would be around $950,000 in today’s money). They had told me that these customers only needed this one feature that they desperately wanted – and that they could wait for the other features later when we released the final product.

Knowing there was a lot of money riding on this, I decided (and informed my manager) that we’d do a special alpha release for these clients. We got a package out in less than a week, and a few days later, I got ecstatic calls from both salespeople that the customers had signed the contracts. This win demonstrated to me the power of this new iterative way of working we did as a team.

In the end, we released the final 1.0 version of the product (and this was a desktop product, mind you) 4 weeks after that alpha release and then released a follow-up 1.1 version 6 weeks later.

The Key Insights

I have a number of things I want to highlight about this very first “agile” project of mine, and I think what made it successful.

• We were a scrappy team. We were a bunch of engineers, one dedicated UX, one half-dedicated documentation writer, and a new project manager who had just joined our organization. We didn’t have a product manager, or much less a product owner (which wasn’t invented yet at that time, mind you – the Agile manifest didn’t even exist at that time).
• We had a vision of what this new software would do with this brand-new piece of hardware that had taken the consumer space by storm (no, it wasn’t the iPhone – this was back in 1998).
• We didn’t have a product backlog. We had a list of problems that were hurting or hampering us. And we went down that list, starting with the most painful and urgent. If the problem was hampering the product, it would be prioritized high. If the problem was hampering the team, it would also be prioritized up high. And we’d decide among ourselves who in the team would work on what.

In short, we were empowered as a team, and as a team, we were prioritizing both customer and team needs in order to deliver something. We got lessons in value immediately via the sales folks and their contracts that were at stake.

We didn’t have a product backlog – we just had a list of problems stacked with the most painful or the most urgent issues at the top. We didn’t know anything about user stories or PRDs. We just said, “Here’s a painful problem – what can we do to fix it?” How do we know if we’re communicating correctly between the device and our workstation? Build a short “Hello, world.” program that would just connect with the device and get back a response. Trouble building things on your desktop? We created automated scripts to do the build – both on our desktops as well as our nightly code repository. Pain at DOA (dead-on-arrival) executables? We immediately built a short automated test suite that tested the nightly builds and sent an email to the team the next day to see if things were OK or not. (We were doing the very early versions of CI/CD, which wasn’t even a term yet at that time). 

Having a problem list that contained both product and team pain points really helped us because, in the end, we needed to solve both types of problems. I see many Agile teams today whose backlog is all product features and neglect things that actually impact team productivity, which eventually impacts overall team health. In going down memory lane with Tom Gilb, recalling my first success with agility, I think that maybe it’s time to go back to simpler mechanisms, where you simply have a problem list that you work on iteratively.

The Final Verdict

Either way – you still need a prioritized list. Whether it is a problem list like I had with my first agile team or a standard Product Backlog in user story format, it is up to you. The key is to prioritize your list, as well as have a balanced list, which balances both the product needs and the team’s needs.