How do we keep our product backlog clean when it’s bloated with so much information all the time? Well, this question had occupied my mind for a while until I recently stumbled upon a related discussion on LinkedIn. This discussion gave me insights into some rules for managing a product backlog and having it lean. I am listing down 7 of these rules for you. You may try using these for fuss-free backlog management. Read on.
#1 – Learn the art of prioritizing. Your product backlog should include only high-level requirements. The scope of the project may include several systems/stakeholders/business functions/departments/deliverable products, but the backlog should not include more than 10 to 20 items. Any detail beyond these 10-20 items can cause complexity and confusion. Any further details should only be considered during the sprint planning phase.
#2 – Adhere to the 6-month rule. The rule of thumb is to remove anything that’s been in the product backlog for over 6 months and still hasn’t been prioritized for sprint. This way the backlog doesn’t bloat with unnecessary ideas, which might be relevant 3 years ago but are no longer pertinent. Discuss this with your product owner and the stakeholders, and clean the dead ideas immediately.
#3 – You can’t go wrong with the MoSCoW methodology. According to this method, the product backlog should be divided into 60:20:20 MoSCoW ratio. Here M stands for MUST, S stands for SHOULD, C means COULD and W stands for WON’T. This means the features which are important enough MUST fall in the top 60% items of the backlog. Then, the features which SHOULD and COULD come during the sprint planning phase. This way you won’t be cluttering your backlog even if your team is unable to complete a particular fraction per sprint.
#4 – Having good Product Owners (POs) on board helps. They constantly groom the backlog, make lists of ideas, bugs and other inputs and timely synthesize them into product backlogs. Before adding anything to the log they analyse the input and weigh its impact on other items in the backlog. As they go ahead in time and come closer to a sprint, good POs have more clarity.
#5 Keep unnecessary grooming minimal. The items which are far out should be given the least attention. Just as you don’t break storyboards into tasks and hours until they are ready to go into sprint, there is no point ranking stories which are X months away from the sprint phase (X depends on the length of your release cycles). You may not even create story points for them as of now, depending upon your management Road Map.
#6 The triage approach is a solid idea. Under this approach, the PO’s, Scrum Master and the Engineering/Dev Team Lead meet on a weekly basis to discuss pre-groom stories and emerging epics before the actual grooming ceremony begins. This meetup helps the Engineering/Dev Lead to understand the business proposition associated with a certain story, and convey the same to his team. Bugs and other defects can also be addressed in such meetings. The Dev team can suggest the PO about bugs, especially the ones with technical dependency. This way the backlog can be actively managed on a regular basis.
Tip: Try limiting the discussion to the next 2 sprints or the current release schedule. The idea is to groom two sprints worth of stories to an extent that they are “Ready”.
#7 Use good backlog management software. These make it easy to categorize stories as already processed or junk, and help maintain the quality of the product backlog. Some good tools available online are tinyPM, GreenHopper, Backlog Tool, easyBacklog and ScrumDesk.
A product backlog is the backbone of any agile development project as it prioritizes the list of desired functionality for hassle-free project management. Thus I came up with this article listing down probable rules of managing a product backlog suggested by various Agile experts. What do you think of these? Are there any rules you follow to maintain an agile backlog? Let us know in the comments section below.
Want to learn more about agile software development? Contact a VenturePact Dev Consultant right away.