How to manage a really big backlog items
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.
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.
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
Sebastian
PS:
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)
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.
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.
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.
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.
Cannot build car in a sprint - try this one: http://wikispeed.org/join-the-team/the-wikispeed-process/