Skip to main content

How to manage a really big backlog items

Last post 02:52 am February 13, 2016 by Andrzej Zińczuk
7 replies
05:50 am August 7, 2015

I need some help in items grooming. Scrum requires to deliver at each sprint the valuable item for Product Owner(customer). But how to be with items that valuable only altogether? For instance, company create a new car. And next highest item in backlog is the engine, and of course company doesn't have the ability to create it within a one sprint. Product Owner doesn't know anything about spare parts like the carburetor, and it doesn't looks like something valuable for him.

03:07 am August 8, 2015

Scrum is not silver bullet or help you to finish a mission impossible.
If you could not engage more teams to deliver an integrated valuable incremental which is too big to be done by one team during a sprint, there were two approach might be considered:
1. Coach the PO to decompose the BIG items or change a PO(if possible)
2. Conducts a worse-to-better iteration approach, deliver a workable product with minimal features in a sprint (if possible), and improve the features in the future.

04:30 am August 8, 2015

Dear Alexander,

Usually we face such situations, when we try to use scrum in a non-agile environment. So behind our sprints and iterations we still think that we actually know what we want in the end and we simply try to generate PBIs from some existing specifications (written down or in our heads).

I could write essays about approaches here, but there IS literature out there, so I will keep it brief.

1. We are NOT building cars, we are building software (I suppose you are?)
So we should not build technical parts separately (like in one layer) we should build small features throughout all the layers.

2. There is this thing we call minimum viable product. A good product owner can determine such. So the first version of your engine might be a more trivial one used in a more trivial car etc.

3. The Increment does not necessarily make sense to release. (If you want to build a bookshop, the login mask itself you will not want to release. Still it is a PBI, it is inspect able and it might cause changes…)

4. A good product owner DOES know carburetor if that really IS a feature as described in 1 and he will want a review about it and he will have feedback on it.

5. DT can help refining!

We DO need to change our mindset from the way we worked earlier radically. This is not easy at all (!) but once you get there, you should normally not face this problem. It might nevertheless very, very rarely occur. Then try to find smaller PBIs that ARE possible again and again - yes this will lead to not having this situation ;).

If it just isn’t possible, I don’t really see another solution then EXCEPTIONALLY splitting the PBI into technical parts and only have them delivered after a second sprint.

Good luck

If nothing helps (and you are sure your mindset and the mindset of your team and mainly your PO are fully agile as is your process and your environment!) and you face this problem multiple times, maybe your team is too small or your sprints are too short. (A team of 3 people delivers not as much in one week as a team of nine people in 4)

07:57 am August 8, 2015

Huge backlog items are considered as EPIC\Theme also know as backbone, these should be further break down into features and further into stories. PO should prioritize these stories with business team to ensure scrum team is working on highest priority stories and delivering value to customer. Also, there is something called Story Mapping, it orders user stories/product feature into logical themes to serve as a plan for development. It also help to identify gaps in business flow of an application, help to build a shared understanding, distribute stories across releases during envision stage and across sprint during release planning phase.

08:47 am August 8, 2015

If a Product Owner isn't interested in product composition, then he or she isn't doing their job properly. Articulating a product in terms of its constituent parts is essential in order to de-risk delivery.

A PO should know and care about what the delivery of each part proves. That's why the ordering of the Product Backlog is one of a PO's key responsibilities. It's also why Sprint Goals are negotiated as a coherence of selected parts, since these can address substantial areas of business risk.

04:50 am August 11, 2015

Thank you everyone for your timely responses. I think the best way for me and my project will be the moving from simple to complex but it also requires a knowledge about process/methodologies that helps to decrease negative influence on the product architecture.

09:58 am August 11, 2015

Hi Sebastian,

What an expert point of view!

In spite of capacity and sprint duration, dependencies of individual works may cause a significant impact for real big items.

You can not make a baby with 9 women in one month.

02:52 am February 13, 2016

Cannot build car in a sprint - try this one:

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.