Do you need a quick way to check and share project status? Use an extended Kanban board for planning and status. Move items from one work queue to the next, from planning to released. You’ll be more organized and always ready with product status.
A typical Kanban board has three phases: To-Do, Working, and Done. For product managers and product marketing managers, you'll need an extended Kanban queuing technique. Whether for stories or tasks, this extended Kanban helps you visualize the work and its flow.
Planning
All ideas begin in the Planning stage. Here, you’ll attach personas, problems, critical dates, outcomes, needs, constraints, and other relevant context as you flesh out the story. This will probably have the largest list of stories.
Ready
Stories are moved from Planning to Ready as a result of a formal discovery session. That is, your product team agrees that these stories are ready to be pulled into development. In this queue, you adjust priorities continually and provide more context. You can add and revise until the story has been turned over to the product team.
To feed the creation team (developers, marketers, or others), you’ll consider only the items in the Ready queue. These items are prioritized for business value but always take into account your own judgment. Just because something has a high priority, it may not be the most important thing to work on next. Look at your ready queue from the standpoint of “What is critical to be done in the next 90 days?” Or, “What must we do to survive?” These items are the ones you’ll want at the top and ready to pull into the Development queue.
Working
The Working stage is only for work in progress—all stories being actively worked by your team currently. Using the “pull” approach, the product team pulls work from Ready to Working only when they have the resources to take on more work.
Ensure your team is cautious to limit work in this queue—the team can easily get overwhelmed by too much work or paralyzed with indecision on what to do each day.
Once a story is in working status, no one should manipulate it. After all, you don’t want your team trying to hit a moving target.
Accepted
The story moves into the Accepted stage when all its required elements—needs, constraints, and outcomes—have been satisfied. But once it’s accepted, you cannot change it. After all, the work is done.
Once a story is accepted, the story sits in the Accepted queue until it is publicly available. For those who release work on a scheduled basis, you’ll build up many items in the Accepted queue and formally launch those stories into the market. For an organization with continuous deployment, the stories could be made available instantly.
Released (or Delivered)
When the story is available to the market, you move it into the Released queue. Some teams prefer to call this queue “Delivered” since the team has delivered the capability to customers.
Formalize Story Acceptance with a Demo
The team pulls work from the Ready queue; the team finishes the work and calls it “done.”
But is it?
Work is not done until it has been formally accepted by a product manager.
If you’re using the queuing method just described, you know which stories are in process. And they cannot leave the Working queue until you’ve seen them working. That is, a story moves from Working to Accepted only when the product manager has determined that all of its required elements have been built and tested.
When the team agrees that the story is done, they demonstrate each completed story to the product manager and other stakeholders. Some call this a “demo.”
Customer needs, outcomes, and constraints define the business rules for a story: it must have this; it cannot have that; it must do this. The demo will show that all aspects of a Product Story have been completed.
Some stories turn out to be pretty big so the team may challenge you to accept a portion of the work and move the remainder back to Ready. That’s okay as long as the portion of work can be safely released to customers. Your goal in acceptance is to make sure you’ve solved a complete problem or scenario.
I strongly recommend a formal ceremony for acceptance. Ideally, the product team will fully demonstrate the story so the product manager can accept or approve the completed work.
Also take time to congratulate the team on their work—everybody likes sincere praise after all.
Here’s the good news: formalizing this flow ensures that the team and the product manager are working toward common goals. And also allows the product manager to share what’s working with other stakeholders.
These Kanban queues represent the state of the product, from what’s planned to what’s available. You can present this information quickly in a release plan or product roadmap.
With this approach, you spend more time planning and working with your customers, and less time trying to figure out which items are in what state.
This is one of the many modern methods taught in the Fundamentals of Managing Products series available from Product Growth Leaders. Learn more here.