Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: backlog

  • Pull and Push in Kanban

    Kanban is a pull system. Period. In Kanban everyone pulls the task from the previous stage to another. Developers pull tasks which are ready, quality engineers pull tasks which are built, release managers pull those which are tested, and so on, and so forth. Basically every operation on the board happens that way.

    Well, almost.

    There is one interesting thing I realized talking some time ago with Nadia Zemskova in Copenhagen. In one situation we usually have push instead of pull operation. When? Consider a typical Kanban board where a backlog is split into two columns: long-term backlog where you put everything you’re going to build and short-term ready column or to do queue where you put just a few tasks of highest priority at that moment. The board which looks like that:

    Now, what is happening here is usually a part of job of product owner or product manager: they have to choose what the most important thing to be build at the moment is and push them into production process. Um, have I just used the word push?

    But that’s exactly what happens. When working with backlog we don’t just pull first thing from because first we have to decide what is going to the top. When we prioritize features we look though all of them as we theoretically have to compare every possible pair of features and say which one is more important or more urgent. We actually decide what exactly will be built in the first place. We push a bunch of features into to the top of the queue or, in other words, into production process.

    From this point the whole process is pull but the first stage works the other way round. There are two differences between first stage and the rest.

    First, when prioritizing features we usually work on big pool of them – actually all of them which are in the backlog. Later we usually don’t have more than just few features to choose among and very often we can pretty safely assume all of them will be completed soon enough.

    Second, at the beginning prioritization is crucial part of our activity – we make conscious decisions what should go first and what should go next. Later in vast majority of situations we can use simple mechanisms like first in first out and it would work well. At the beginning we can’t go with something like that as we’d be building our software in rather random manner. And that doesn’t sound like a great idea if you ask me.

    That is why we retreat to the good old push to manage backlog.

  • How to maintain backlog?

    In one of recent postings I asked you how big your backlog is. My argument was that trying to enforce small backlog size is counterproductive. Although small backlog is easier to manage throwing things away from it just to keep it small isn’t the best idea.

    However that doesn’t mean you shouldn’t do some backlog maintenance from time to time. What more, applying a few simple rules can help you to manage backlog easily despite its pretty big size.

    Keep epics, split late

    Sometimes we add to our product a big story. An epic. It is actually pretty interesting example in terms of sizing backlog. Why? Well, no matter if you split the epic into a list of smaller stories, i.e. sized similarly to your typical features, or keep it big you add a huge piece of work. A piece, which usually makes sense as long as it is completed as a whole. So yes, you need quite a capacity to add the feature, no matter which approach you choose. What do you do if your backlog is limited?

    Anyway, my advice is to keep epics in backlog as long as possible and split them in the last responsible moment. It is aligned with agile late design approach but that’s not why I advise you so. Actually as long as you don’t start working on the epic there’s no reason to keep a dozen of sticky notes on the board instead of a single one. It’s enough for you to look at epic to know roughly what is to be done. You will need more details when you start development of first epic-related feature so no need to worry at the moment.

    It is easier to reprioritize the epic over and over again if it’s in one piece. And reprioritizing is the most common task when it comes to managing backlog.

    Groom from time to time

    If you have spacious backlog you will face this situation on occasions: you will find out that one or more features waiting in the backlog are no longer relevant. Maybe you’ve changed the goal of your app or you abandoned industry which was addressed with the feature or you just don’t have a faintest idea why you wanted to build the damn thing in the first place. Either way it’s time to forget about it.

    Grooming backlog is a great occasion to do that. What exactly grooming is? A simple process of reviewing all features in backlog to verify their relevancy. Yes, if your backlog is big it takes time. But after all this is the way to make it at least a bit smaller, thus more manageable. And you don’t do it every week as you don’t change general plans for your product that often.

    Group features

    There’s an observation which can be helpful as well. Unless we work on maintenance project where priorities are usually set by the client we tend to build groups of similar features and not randomly choose one from here and another from there. Grouping features which are similar or features which touch the same parts of code can be helpful in terms of prioritizing work. Once done you can just throw in another feature from the group instead of scanning through the whole backlog to look for a relevant task to put in todo queue. That is as long as your general priorities don’t change.

    Grouping features also helps in prioritizing whole backlog. Instead of considering each and every feature separately you decide on a group which means you use the same time to judge a dozen of tasks you’d use to judge a single task otherwise.

    Dealing with big backlog isn’t that hard after all. All you need is some order and a few rules which help you to organize a long list of tasks somehow.