As soon as somebody says you’re spending too much time on something, you’re on the right track.—Bob Lefsetz, American music industry author.

There are two approaches to delivering stories to your product team: pull and push. Typically, product managers and executives “push” more and more requests to the developers. Even though the team already has a bunch of things, we push another few and then another few and then some more until the team is paralyzed with unfinished work. In more practical terms, the product manager builds a long list of prioritized requirements, perhaps grouping them into themes or releases, and sends the developers a few hundred items at a time. This is probably the most common scenario and tends to have three negative effects.

First, a long list of stories is overwhelming to the team, which damages their spirit and hurts productivity. Second, this approach tends to give you a whole bunch of disconnected stories so you have 80% of everything but not 100% of anything. Finally, pushing a lot of work at one time means you can’t reasonably re-prioritize the work when business conditions change.

Rather than pushing a bunch of work to developers, I prefer to let them “pull” work when they’re available to take on new tasks. In this scenario, the product manager maintains a long list of prioritized work. Developers request more work when they have bandwidth and the product manager hands them the next thing on the prioritized list.

One of the chief ideas of Kanban is to limit the amount of work in progress. Each developer works on one item at a time. They work until they’re done and then ask for more work. The product manager maintains a steady queue of work in queue.

Since the product manager is constantly prioritizing the list, the most important items are always on the top of the queue, waiting for development bandwidth.

Task switching is a well-known detriment to productivity. You want to avoid changing the work that has begun. Never mess with work-in-progress. But since no work is being done on your story queue, you can always add items to the top, bottom or the middle based on their importance.

In one product management job, I was told the development team was terrible; they couldn’t seem to finish anything. Investigating further, I found the problem wasn’t with the developers but with the executives. They were changing the priorities constantly. They didn’t seem to realize that one sentence from the leadership team meant weeks (or months) of work for the product team. I found the developers to be quite competent but with an ever-changing priority list, they couldn’t complete anything before a new #1 priority interfered.

We switched the team from a push approach to a pull technique. We didn’t mess with anything that was in progress. All new ideas went into the product manager’s queue, was prioritized based on business value, and then delivered to development when they needed work. That meant that executive pet projects could be put on the stack and then delivered to the team when the item became a top priority.

It also meant that bugs and architectural stories could be delivered to development just like requests for new functionality.

And when you’re working in short cycles, new important items can be started every week or so. It’s not like we have to wait a month or a quarter to begin a new initiative.

Are you using a “pull” method with your team?

About Steve Johnson

Steve Johnson is a product management process coach, author, speaker, and advisor. His approach is based on the belief that minimal process and simple templates result in a nimble product marketing and management team. Before founding Under10, Steve was a Pragmatic Marketing instructor for over 15 years and personally trained thousands of product managers and hundreds of company senior executive teams. Learn more at www.under10playbook.com

In his spare time, Steve enjoys making music, and has an album available on iTunes. Check out Steve’s music at notExactlySteve.com