The product backlog has over 200 items. Is this acceptable?
Welcome to part 3 in our scrum master interview questions series where John McFadyen answers common questions asked of scrum master and agile coaches in interviews and client engagements.
So, you’re asked whether it is acceptable for a product backlog to have over 200 items. In my opinion, it completely depends.
What are we talking about?
Are we talking about 200 small items that are an absolute necessity to building and launching a new product? Would it take 2 weeks to complete all 200 items? If so, yes, it is completely acceptable to have 200 items in the backlog.
If we are talking about 200 grand ideas that don’t create value for customers or solve specific customer problems? If so, no, it isn’t a great idea, and the team should refine the backlog.
The purpose of a backlog.
When I work with agile teams, I talk about the importance of a backlog that has, at minimum, enough items ready for us to complete in a sprint.
The sprint length is decided by the team and generally falls into a 2-week or 4-week cadence, but it could be anything between 1 and 4 weeks. So, as a starting point, we aim to have enough backlog items ready for the team to tackle and complete within that sprint.
A great rule of thumb is to have refined the backlog into at about 2 weeks’ worth of work.
Scrum is built on the idea of frequent delivery of valuable products or features to customers.
We aim to build a feature/product or solve a complex problem within the sprint. The goal is to provide a working item that a customer can review and provide feedback as to whether it serves their need or solves their problem.
The backlog needs to serve that purpose.
It needs to contain a list of valuable items that actively help customers solve problems or achieve the goals and objectives that matter to them. If the backlog isn’t doing that, it isn’t a valuable backlog and the team need to work with the product owner and product stakeholders to create one.
Scrum Team Delivery
It is incredibly hard for a developer to assign a time frame to an item. In other words, an estimation of how long it will take to build the product or solve the problem.
They simply can’t know what they don’t know and so they will only know once the work is complete.
For this reason, developers estimate how much effort is involved in the delivery of an item or use a range of measures, such as small | medium | large, to estimate the difficulty of completing that item.
Over time, the team become pretty good at estimating how much work can be delivered within a sprint and can use that as a forecasting tool to help provide rough estimates for future delivery.
If the team consistently deliver 20 points worth of work within a given sprint, and the entire backlog comes it at around 60 points worth of work, then 200 items isn’t a problem at all. It would only take roughly 3 sprints for the team to work through the entire backlog.
If the backlog consists of roughly 2,000 points of work, and the team are consistently only able to deliver 20 points worth of work in a sprint, then you would benefit from a backlog refinement event that helps the team streamline the backlog into valuable and necessary items.
Hosting a sprint retrospective to understand why the product backlog has so many items on it and why the team aren’t able to consistently deliver against their goals and objectives would be a valuable conversation to have.
Product Owner intervention.
The goal of agile is to create an environment where the team can excel.
The backlog, whether in scrum or Kanban, is a tool that empowers developers to pull work, in order of value and priority, and complete the work in short, sharp bursts commonly known as sprints.
If a senior leader in the organization or powerful stakeholder is simply populating the backlog with a wish list of things they want to see, rather than actively working with the product owner to identify and articulate valuable work, then you have a problem that needs to be addressed.
In a project management environment, this is known as scope creep.
It happens when powerful project sponsors, stakeholders and senior managers get into the habit of adding things ad-hoc and at whim, which leads to burnout and project creep in terms of timelines and escalating costs.
Agile aims to avoid that by positioning the product owner as the virtual CEO of the product and provides the scrum team with autonomy to decide which items are the most valuable and in which order they should be completed.
If powerful individuals are insisting on adding items to the backlog, your product owner needs to step up to the plate and have difficult conversations with those individuals to help them understand why scrum works the way it does, how it serves both customers and the organization, and why it is necessary for that individual to engage with the product owner if something needs to be added to the backlog for refinement and production.
Backlog Items Summary
We need to be clear about the value of the items that we add to the product backlog, and it is useful for us to know how much effort or difficulty is involved in delivering the item.
If it takes an average of 5 minutes to deliver an item on the backlog, 200 items isn’t a problem in the least bit. If those items take a long time to deliver and it isn’t clear what value the item will contribute to the customer, then 200 items is too much.
The number doesn’t matter as much as the state of the items.
We need to engage with customers to check whether the items on the backlog are still things that are valuable to them or whether we should scrap those items and replace them with items that are valuable to customers.
It’s a constant process of refinement.
We inspect the items, collaborate with customers, and adapt based on the customer response.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster