Sprint Planning or Queue Replenishment Meetings are a Breeze with a 2D Backlog

Again I’m blogging because something I take for granted received the comment, drug “You should write a blog post about that.” In this case, it’s a tool the Kanbanery team uses for queue replenishment and it was Paweł Brodziński who saw it on my wall and said I should blog about it.

About a year ago when the team was proposing multiple ideas from the backlog during a queue replenishment meeting (Sprint planning to you Scrum folks). We were looking for three ideas from the dozen being tossed around, so I wrote them all on Post-it notes and invited the team to pretend the coffee table was a graph with two axis: value and complexity. We found it pretty easy to agree on where all the Post-it notes belonged relative to each other. Two quick wins (high value/low complexity) emerged and a group of three options were the clear next choice for the third position. As a result, rather than debating the relative merits of a dozen features, we were just talking about three features for one free development slot and we had already agreed that all three had roughly equal merit, so the decision was mostly one of preference.

I don’t think all queue replenishment meetings should be held this way, and we’ve incorporated other tools as well, such as impact mapping and class of service limits, but we still incorporate the value/complexity graph into our decision-making.

Presently, as new ideas come up, they are written onto stickies and stuck on a wall chart. We don’t always pick only the quick wins (or quickest win), because we understand that some work is strategic in nature and worth the investment, but it still helps a lot to focus our thinking.