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.
January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back and recall the most interesting blog posts by TargetProcess in 2009 :)
Based on visitors count, the posts are ranked as follows (descending order):
1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.
2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management :)
3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.
4. Tale: Deadline and Technical Debt: Once upon a time… Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? :) There we go: smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.
5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong” instead of “what’s right” …
6. How We Use Kanban Board. The Real Example: Once we figured that Kanban process is just the right thing for us and put it in action, we shared this experience with our blog readers.
8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.
I’ve started using BDD to create user stories specifications several months ago. It works great. Very good format. Developers understand it without problems, Testers can write acceptance tests quickly and it is easy to follow for Product Owner.
Here are some examples of real user stories specs in BDD for TargetProcess product:
As a Scrum Master I want to see Release BD Chart drawn by weeks
As a Scrum Master
I want to see Release BD Chart drawn by weeks
When Iterations practice is disabled
So that I can benefit from BD chart
Given any development process
When I turn off Iterations practice in Admin -> Process -> Edit
And navigate to Release BD chart
Then iteration velocity replaced by weekly velocity
And Chart end date is the same as Release end date
And BD chart drawn by weeks instead of iterations
And Chart Start Date is the same as Release Start Date
As a Scrum Master I want to see Lead/Cycle time progress
As a Scrum Master
I want to see Lead/Cycle time progress
So that I know whether we are improving our development process or not
Scenario #1
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 1 line for stories
Scenario #2
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Cycle Time
And chart contains 1 line for stories
Scenario #3
Given Reports section in project and Bug Tracking practice is ENABLED
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 2 lines (for stories and bugs)
Scenario #4
Given Reports section in project and Bug Tracking practice is ENABLED
When I navigate to Lead and Cycle Time Report
Then I see Cycle Time
And chart contains 2 lines (for stories and bugs)
Additional Info
X-axis – Months (display 12 last CALENDAR months)
Y-axis – Lead time or Cycle Time (in days)
To display value for given months, we take stories completed this month (determined by End Date).
For example, in June we’ve completed 5 stories, in July 10.
Then lead/cycle time will be calculated for June by sum(5 stories lead time)/5 and for July sum(10 stories lead time)/10.
