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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
6 comments… add one
Cool tips!
I totally agree with the “Keep epics, split late” advice. My team and I used to split epics to have a ballpark for the cost, but it turns out you can have a pretty good approximation if you simply use an order of magnitude (we usually use Fibonacci numbers for this). That avoids the frustration of detail planning something that will not get done.
Regarding the last advise, “Group features”, we rather “Group stories”. This is a great way to determine what’s more important in a feature, and helps prepare the ground for Sprint demos.
Rodrigo,
This is the problem I constantly face: we use different labels to name the same things and we use the same labels to name different things. When I say features I think more about MMF (Minimal Marketable Feature) which in our case is pretty close to reasonably small user story.
So I guess I could have written group stories as well. Anyway the key thing here is grouping activity. If you group relevant, well, things they become more manageable.
Hi Pawel,
are there any online tools you would recommend for maintaining backlogs? We are currently using a Google spreadsheet with individual tabs for different work item types (revenue related work items, product related work items, intangibles etc. – all with different stakeholders). Therefore, we are discovering some difficulties to evaluate, prioritize and then consolidate everything into one backlog list. Any suggestions?
Thanks!
Nina,
At my current team we use sticky notes on the Kanban board and excel sheet as backup so we aren’t even that advanced.
The trick is the real thing, like the whiteboard, does a great job in terms of visualizing things. It’s easy to distinct projects as we use different color of stickies for each project. It’s easy to group features. It’s easy to add any important marker (we had a blocked feature in backlog once).
Visual board helps in prioritizing, but it doesn’t really help in day-to-day backlog maintenance. It also doesn’t scale up very well – there is only a certain number of sticky notes which you can put on the board. So the question I’d start with is: what is your current problem with backlog?
Depending on a problem there would be different solutions. You can consider moving to some web-based tool (any bug tracker or task management tool should work to some point) or leave it like it is or use less of software and more of something else.
Fascinating subject that is much under considered. To me this is the key to a project’s success. I agree with the post. I try to formalise the process in my mind so I can learn what works.
Here’s how far I’ve got: Definitions are a necessity. Witness the confusion over the word ‘feature’. When we use a word we all need to know we agree. A feature is not defined as far as I know. So we need to define it and everything else we use to discuss requirements/story management. I start with a engineering glossary that describes how one concept relates to another. It helps me and is designed to act as an aide to the team. It stands to reason the team takes an interest in how the requirements are represented. So we at least need to understand terms like feature, epic, user story, iteration story, and task.
Every function in the engineering process has a ‘customer’. I do the job of grooming the product backlog. It’s a full time thing. The customers are the developers who are going to ultimately play planning poker with the requirements. My way to do this is to bring a well constructed epic to an exploration meeting. The objective is to give the developers a view in context of the functional area the epic covers. From that we pull out each of the stories (having understood how they relate to each other) and play planning poker. The epic that goes into planning is the one with the highest priority (or just the one that is obvious – we can seldom deliver observable customer benefit in early sprints).
I said it’s a full time job to groom the backlog. This is because I am a recent convert to Behavioral Development (using cucumber style tests). So the user stories are primarily a description of the tests that will demonstrate the utility of the behavior being built. This way the product owner demo is made much easier.
Grooming the backlog is a project overhead. Is it worth it? It’s all about getting the team working together and then doing productive work. If requirements aren’t managed well, it isn’t long before the project drifts.
The other advantage of structuring the backlog is that it can be managed and give project metrics. This area of project metrics only makes sense when applied over a well managed backlog. Otherwise the metrics don’t mean anything.
Too often I’ve seen terrible software demos to product owners. It is, after all, a show. The demos are the part of the project that keeps it all honest. When these are poor, the project is not running well. Or so it seems to me.
@Peter – A few words of comment to what you’ve written. Frequency and amount of time spent on backlog grooming much depends on project characteristic. The more change there is and the more frequently priorities shift the more work it costs you to keep the backlog clean.
Another variable is project size. There’s way fewer tasks when you work in a team of 4 than when you work in a team of 10 (and it rarely goes up linearly). In other words there’s a difference in how cluttered the backlog is, thus amount of work spent on cleaning it differs.
I fully agree on common definitions. I’m not that fond of formalizing definitions however. The key is common understanding. If we have it – we’re good.
Now, you might ask a question how do I know? One trick I sometimes use is I’m asking different people what does it mean that this or that index card is in this or that place of the process. I expect people to give me the same answers.
You totally ask the same questions even if you don’t have a board – they will just sound a bit differently. What does “development done” mean? What do we need to start development at all? When are we done? When are we done-done (if that’s different from done)? Etc.