There are two approaches to delivering work to your product team: push and pull.
In many organizations, product management and executives are pushing more and more requests to developers. In practical terms, that means product management builds long backlogs of prioritized requirements. They group them into themes or releases and send developers a few hundred items at once.
This long list of stories can overwhelm developers, damaging their spirit and productivity. And over time, they may become paralyzed by their unfinished work. This push approach also tends to deliver a lot of disconnected stories. You end up with 80 percent of everything and 100 percent of nothing. Most important, pushing a lot of work at once makes it challenging to reprioritize that work when business conditions change.
But there is an alternative. Instead of pushing work to developers, let them pull work whenever they can take on new tasks. In this scenario, the product team maintains a comprehensive list of prioritized work that can be reshuffled at any time. When developers have the bandwidth, they request more work and product management shares the next item on the prioritized list.
Let me share an example of why this is helpful. While consulting at one company, I was told the development team was terrible; they couldn’t seem to finish anything. The problem, I discovered, wasn’t with the developers, but with the constantly changing priorities. And with an ever-changing priority list, the developers couldn’t complete anything before another new “top” priority interfered.
To remedy the situation, we switched the team from a push to a pull approach. New ideas went into the product management queue, where they were prioritized based on business value and then delivered to development as bandwidth allowed. We never interfered with anything in progress. Working in short cycles meant we didn’t have to wait months or years to begin a new initiative because important new items could be started every week. By allowing development to complete all work already in the queue and prioritizing new work based on its business value outside of that queue, productivity increased dramatically.
Product Stories and the Five Queues
The five queues—planning, ready, in progress, accepted and released—are based on the kanban principles for managing and improving workflow. To implement the pull approach, you leverage a series of staging queues with each product story moving from one stage to the next as it progresses.
Using these queues, product management can see the status of any story. In addition, they can ensure that only a few items are in the in progress (or development) queue.
Planning
All ideas begin in the planning stage, where you can flesh out the context with personas, problems and critical dates.
Many teams have a large number of items in planning: architectural epics, executive projects, customer requests, competitive parity features, etc. These items need to be validated in the market to ensure they’re worth doing. That’s why the planning queue is for product management, not developers.
As you discover more information, such as outcomes, needs and constraints, this gives you a place to document it in the story to ensure that all your business logic is in one place.
Ready
The ready queue is for stories that are ready for development but haven’t been shared with the team. In this queue, you can continually adjust priorities and provide more context until the story is turned over to the development team.
However, just because something has a high priority, doesn’t make it the most important thing to work on next. Be sure to ask, “What is critical to be done in the next 90 days?” or, “What must we do to survive?” These are the items you will send to the in progress queue.
In Progress (or Development)
The in progress stage is for active development. All the items currently being worked by your development team live here. Work will be pulled from ready to in progress only when the development team can take on more work. It’s important to limit work in this queue, as teams can become overwhelmed if there is too much inside their backlog.
Accepted
Product management hands work to the developers; developers finish the work and then we call it “done.” But is it? Maybe you’ve heard the phrase “done done.” It’s not done until the work has been formally accepted by product management.
A story moves into the accepted stage only when all its required elements—needs, constraints and outcomes—have been satisfied. The development team demonstrates each of the elements so the product team can accept or approve the completed work.
The product team must acknowledge that the feature works as expected and is ready to go into production to move to the accepted stage. And only in this stage can the product team discuss that feature with salespeople and customers. A feature sits in the accepted queue until it is publicly available.
Released (or Delivered)
When the story is available to the public, it moves into the released queue. Now take a moment to celebrate.
If you want to ship a production product, be sure to maintain a backlog of planned work. Add new work to the master list, and don’t allow anyone to bypass that list. Be sure to prioritize all new ideas for their business value and continuously re-sort that list. Then when the development team asks for more work, the top priority will be available.
Whether it is an executive priority, a customer commitment or an architectural epic, the five queues ensure that you will deliver what is most important to your company and customers.
##Callout##
