What is a Product Backlog?

A Product Backlog is one of the three Artefacts in Scrum but in truth, it is used all over the place and not just in Scrum. It is essentially an ordered list of items that you believe are needed to create and improve the Product over its life cycle. This can range from creation to the end of its life cycle. In the Product Backlog we look at all the desired outcomes and what their purpose is.

What we are trying to achieve here is not just a whole bunch of tasks but rather what we want: valuable outcomes that can be delivered, are usable and useful. 

The Product Backlog outcomes must be valuable to:

🚀  The product. 

🚀  The team. 

🚀  The stakeholders. 

🚀 The customers. 

The Developers and The Product Backlog

In ensuring the smooth sailing of the Product Backlog, the Developers are a key contributor. Together with the delegation from the Product Owner, the Development Team receives a list of prioritised tasks that is typically derived from the roadmap and its requirements.

The most important tasks or items are displayed at the top of the Backlog list so that the team knows what to work on first, and maintain an agreed working pace as they go along the completion of each Iteration. 

One way to look at the Product Backlog is to see it as a connection between the Product Owner and the Development Team. For example any interruptions made by the Product Owner could disrupt the workflow of the Developers, and visa versa.

Therefore it is paramount that there is transparency and collaboration between the two. 

How Product Owners Support the Product Backlog and Development Team 

The best Product Owner is someone who has the qualities of a great leader. And this does not mean that you sit behind your Development Team and micromanage everything they do.

No, it requires you to have trust in your team, know what they are best at and enable them to figure out tasks independently. Furthermore you need to be able to delegate and communicate tasks and goals clearly so that both you and the team as a whole have clear objectives of what they are trying to achieve at the end of each working day. 

How the Product Backlog Differs from Traditional Ways of Working 

In the traditional way of working, we may have an unprioritised ordered list of all the things we need to do. In the Product Backlog however we prioritise our listed items that are influenced by a range of factors and capabilities.

Another difference is that the Agile way of working means that the Product Backlog and Sprint can change from day to day as you learn more about what is needed and what is lacking. I therefore like to think of the Product Backlog as our best guess for what is going to get us to where we want to go but that nothing is entirely set in stone. 

One of the best examples I can think of was when back in the day everyone had sticky notes on the wall all beautifully formatted and refined. The flow was fantastic! The worst one I have ever seen was when the Product Owner of an organisation I was working for had a Product Backlog with over 6000 items. Which I am sure you can already realise, was completely unmanageable and far too in-depth.  It was incredibly task focused and the team had been working on it for too long. 

The problem I identified with this Product Owner and team was that they did not know how to deal with complex problems and when we are dealing with complex problems, we do not actually know what is needed. So as a result I regathered with the team and Product Owner to revise their Product Backlogging into a more usable and goal-orientated format.

As a result we got the scale down from 6000 items to only 600 items, and by the end we even scaled it down to a bit over 300 items. This was much more manageable for the team, and I think that’s when we all really started to see tangible progress. 

So in summary, I think a good Product Backlog:

🚀 Considers the capabilities of the Developers. 

🚀 Refines and condenses items as much as possible. 

🚀 Ensures items are usable and goal-focused.

🚀 Meets the needs of the Stakeholders and customers. 

Interested to learn more about how to run and maintain an effective Product Backlog?

Get in touch today and let’s work together on your journey to success! 

Pragmatic Shift is a Scrum Training, Agile Consulting, and Agile Coaching consultancy that specialises in delivering Scrum.Org certified scrum courses, and helping organisations increase their business agility and product development success through agile consulting and coaching.

We firmly believe that a shift to agile is a pragmatic shift. A natural evolution from traditional project management and product management. A proven, reliable, and resilient framework for addressing compelling problems and developing complex solutions.

Over a decade’s worth of experience as an agile practitioner, agile consultant, agile coach, and scrum trainer informs our pragmatic approach to change. Agile dogma has no value in the context of product development or organisational change.

Instead, we look to start where you are, work with what you have, and make meaningful interventions that align with the objectives you are trying to achieve.

Progress over perfection.

If this sounds like a pragmatic solution to you, visit the following pages for more information.

Scrum Training: https://pragmaticshift.com/training/
Agile Consulting: Coming Soon!
Agile Coaching: https://www.thescrumcoach.uk

#scrum #scrumtraining #agilescrumtraining #scrumorg #scrumcourses #scrumcertification #agile #agilecoach #agileconsultant #agilecoaching #agileconsulting #agiletransformation #agileadoption #scrumcoach #scrumworkshop #scrumskills #scrumtips #scrummaster #productowner #agileleader #scrumdeveloper #developer #projectmanagement #agileprojectmanagement #productdevelopment #agileproductdevelopment