Show all posts
7 years ago

Product Backlog: Small Steps vs. Giant Leaps

When reading this Kill Your To-Do List blog post, I thought that managing personal to-do list can be similar to product backlog management. Not in the part that you should totally kill your product backlog, but in the "one thing at a time" part. This is by no means a new thought.  E.g.  Mary Poppendieck was heard saying that product backlog should be eliminated.

So, as in to-do lists, there's no point in nurturing and moving product backlog items back and forth.  In this case, a lot depends on what is your definition and understanding of product backlog. I'd say backlog is an environment in which a product grows and exists but not a set of components that should be implemented for sure.  Looking further into, what kind of environment is it? Backlog might be a repository of all the slightest shades of ideas that have a very vague chance to be implemented. A chaotic heap. This heap can hardly be called a "backlog" but rather a by-product of brainstorming. OR a product backlog might represent a careful selection of user stories that will be implemented for sure.

Both of these options, as often is the case, have the optimal state somewhere in between. In our production workflow, we're now using several buffers - the first layer is raw Requests and Ideas (coming from our HelpDesk, or from the PO, or from the team). The second layer is Product Backlog with User Stories (Requests and Ideas are now groomed and converted to User Stories by  Product Owner who decides that some time these will be implemented for sure - based on how many people requested this feature, based on current product development strategy etc.). The third layer is Planned state for User Stories in Kanban board.

Here's a quick graphical representation of this product backlog upward funnel:
That's how User Stories lifecycle looks on  Kanban board, from Planned state on:


Backlog is not seen on Kanban board.  When done with their current user stories, developers  pull new user stories from Planned state.

Previously, when we worked with iterations before switching to Kanban, there was no buffer between inception and implementation - so time-boxed releases and iterations have been planned directly from the backlog. With Kanban, the buffering  is done by moving stories to Planned state and prioritizing them.

I'd say that planning with iterations provides less flexibility than planning with Kanban. As you drop user stories to time-boxed iterations, you  commit to implementing all of them within a given period of time. Kanban is way more flexible since user stories can be pulled one-by-one from Planned state and implemented with no time restrictions. I can't resist citing an analogy here: it's the same as moving with the smallest possible steps to posture yourself before hitting the ball in tennis. With large steps, you do not have flexibility. With small steps - you're very agile and flexible to position yourself for the perfect shot.

So, the buffered Planned state in Kanban is like this breaking down into small steps, instead of taking one giant leap and committing to the whole pack of user stories in iteration.

That's the way it goes for us. You're better off moving by small steps, taking it one-by-one (this brings us back to the inspiration blog post reference in the beginning 🙂 than with giant leaps.

  • Steffen

    What is the difference bitween your “WIP” (work in progress?) state and the “In Progress” state on your picture?

  • indigo777

    Take a look at this blog post:… You&#39ll see the WIP Bugs state there (this post was written in October 2009). Now we renamed this state to just WIP. These are bugs that need to be fixed urgently or user stories that need to be worked on urgently. In Progress state is actual work in progress.

  • Robert Mischke

    We started to use iterations in a kind of KanBan way.. where the current iteration is just a collection of things coming next. Often we only have user-stories and bugs in the current iteration, but not further ahead. In comparison to our KanBan style projects, I like that the estimation aspect is more prominent. We can see or guess, what we can achieve in the current week.

    For more structuring we started to use releases, which are for some projects not bound to features, and always a fixed length month long (e.g.: 2 month).

  • Steve Wilkinson

    Very much like the idea of keeping focus on your top priority stories (in fact, the “Kill Your o-Do List” link was a big help for me as a marginally compulsive, somewhat dissatisfied GTD disciple).

    Do you mind me asking, what tool do you use to keep your Ideas Pool (~1k ideas) in?

  • indigo777

    We use our product. Requests pour in, we review them, mark them as Issues or Ideas or something else, then we tag them. This is like some sort of purgatory for Requests/Ideas before they get converted to User Stories 🙂 Check the visuals here:

  • indigo777

    looks like Iteration is your container for what we&#39ve got in In Progress state.

  • Sameh

    Usually user stories have controlled size variation. I am fan of Kanban and I used Scrum. The way the user stories are structured that they can be completed in 1-2 sprints. Size is estimated in StoryPoints to match with the team velocity. For example, if a team&#39s velocity is 20, then the user stories are in the backlog are organized around this range.

    If we have a user story which has size 40, then it will take 2 sprints to complete. An MMF can have multiple related user stories.

    Thank you,

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy