Nov. 16, 2011

Tips and Tricks for the beginner Product Owner: How long is your backlog?

It is not the size of your Product Backlog that matters!

Many Product Owners I coached are obsessed by the length of their Product Backlog. While the fact that I only encountered three female Product Owners in my whole career, might explain parts of this phenomena, there is more to explore about this.

A newbie Product Owner is often frightened about his backlog being too short. Having 15-20 User Stories ready for the next Sprint Planning is often hard for a beginner. After a while, it turns into an obsession, as a long Product Backlog gives a feeling of safety.

Guys, and the few Gals out there: It is not the size of your Product Backlog that matters! Keep three interesting numbers in your mind (from Dave Snowden):

5 - Number of things an average human can simultaneously keep in his mind

15 - Number of people a human being can trust

150 - Number of people we can keep as acquaintances (see Dunbar’s law)

You should be able to keep your backlog in your head. This is why it is not a good idea to let your backlog grow over 150 items at any given time. - If we cannot relate to more than 150 people, we cannot relate to 150 backlog items. Once it exceeds the 150 items limit, some of them are just going to be overlooked and this is worse than if they were not existing at all. Your relatives are going to be upset if you forget about them as well!

„Backlog Grooming“ does not mean to constantly slice all backlog items into little pieces. It does mean to keep the Product Backlog „detailed appropriately“ (see DEEP acronym). So keep your top requirements sliced into small pieces and wait with slicing the rest until it is their turn. Some items may never emerge to the top and will clutter your Product Backlog for a long time if you are not careful. It is a wrong assumption that anticipating work on low priority Backlog items will increase your efficiency , when it will be their turn to make it at the top of the backlog, they will have changed so much that you will have to start all over again.

Also, don‘t bother yourself or your stakeholders with low priority items. - And also don‘t bother your developers with estimations for those items, instead keep the Product Backlog as short as it can be. Consider having ready not more than the double of the items that normally get pulled out of the backlog for one sprint, more than that might be  waste.

Instead, focus on the top items and prepare the next Sprint. Part of the preparation for next Sprint is also the context, so be also ready to talk about the high level requirements for the next 3-4 Sprints and keep them high level.

Your backlog is your weapon for maximizing the return on investment and get your work done as well as transparently share what the defined order of execution is. Handle it with care and care for it often. It shall be detailed appropriately, the top items estimated, emergent and most important - ordered! (Meaning there is one priority 1 item and one priority 2 item and so on.) These attributes will be subjects of other blog posts in the future.

Keep it short enough to stay on top of it and long enough to allow your teams to chose which items to work on in the upcoming sprint.Remember also to provide enough context and direction about where the whole product is manoeuvring to. Its quality and not size that matters!

Image of fivancsich

Franz Ivancsich

blog comments powered by Disqus
Image of fivancsich

Franz Ivancsich

Latest Posts

Why are organizations not seeing the benefits of doing Agile?

Due to a difference in goals and approaches, friction occurs between Agile teams and the rest of the organization - who has yet to see the benefits...

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Agility requires cultural change

Article published in German magazine

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Agile in Everywhere: Sales

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP Berlin

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP