Defrosting the icebox (and other clever analogies)

April 1, 2014 Nic Werner

First, there was the Backlog. And code was shipped to much rejoicing. But Agile demanded more, and the Icebox was created.

What is the icebox?

No, it’s not a place where you can take half-baked stories and heat them to a semi-palatable feature. The icebox is literally where all your ideas go that you don’t currently plan to build. It doesn’t mean you can’t thaw them out later, but to you it represents what you should be investigating further, and to the team it represents a place for all their ideas. Where the backlog consists of features/bugs/chores that you definitely plan to build, the icebox is your holding pen for everything else.

Whenever you have an idea or need to remember something, put it in the icebox

The Icebox is the dumping ground for all your thoughts. Did you wake up at 3AM remembering a certain feature necessary for launch? Icebox. Shower epiphany about a new user flow? Put it in the icebox. Don’t write out the full story, just the placeholder title to remind you of your brilliant idea.

And be careful of using disparate systems. Think about it: Your Tracker project is where ultimately all development begins. Coding doesn’t start until it’s in *that* system. So don’t give yourself extra work by putting an idea into Asana only to have to copy it over later.

How Should I Use It?

With a nod (and apologies) to David Allen’s GTD style, your icebox should be partitioned into:

  • Upcoming
  • Inbox
  • Bugs
  • Chores

In Tracker, you can use release markers to break up the icebox. Click ‘New Story’, and choose the type to be ‘Release’.

Upcoming: This is your scratchpad for upcoming development. Put stories in here that represent what you want to build next, and this area is instantly your To-Do List: Do I need to talk to Accounts Receivable about integrating with their system? Can I quickly write this story in the next 15 minutes? Pick the top item off the list and take action!

Once you’ve fully investigated the details of a feature and written out the story, take it out of your Upcoming and put it in the backlog to be pointed at the next IPM.

Inbox: Simple and straight-forward, this is the afore-mentioned dumping ground of ideas. Put everything here, and get in a regular habit of reviewing this list and pulling them (up) into the Upcoming area.

Bugs & Chores: These two separate areas are also a catch-all, but you should be reviewing chores regularly with your dev lead to ensure high-priority chores make it into the backlog. For bugs, any high-priority bugs should already be in your backlog. Anything lower priority goes in this icebox area.

Pro Tip: Get the best of both worlds.

As a PM, you are the lightning rod for feature requests. They might not always be feasible with your current roadmap but you don’t want people to think you’re ignoring your ideas. When marketing, customer support, etc. emails you with a feature request, tell them you’ve put it in the icebox. Once they see that you have an area for their ideas, you’ll gain their respect. If they’re really pushing for that request, they will follow up: that’s the perfect time for a conversation about *what* user would want this feature and how they envision it to work.

Finally, remember that visibility is a crucial requirement for a high-performing team. When you keep your Icebox refined in the above fashion, the team sees your thoughts on the upcoming roadmap, and they also know where their ideas can go. You may be the product owner, but ideas come from everywhere!


About the Author


Testing JavaScript Promises
Testing JavaScript Promises

tldr: Testing promises is surprisingly hard. I wrote a mock-promises to address it. A recent project of mi...

This Month In Data Science
This Month In Data Science

With GigaOm's Structure Data Conference, the Pivotal HD 2.0 release announcement, and big cloud platform an...

SpringOne Platform 2019 Presentations

Watch Now