Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
If your Product Backlog contains hundreds of items - many that are years old - and even the Product Owner isn’t sure what all is in there, it may be time to do some clean-up.I get it. It’s tempting to keep a history of everything that was ever requested. But remember, that’s not what a Product Backlog is for. A Product Backlog is your strategy going forward. It’s not a history lesson. And treating it like a historical record takes away from its value.So please treat this message as permission, encouragement, or whatever you need to get out there and either delete or archive old requests. Do whatever you need to do to get them out of the Product Backlog. If you need a historical record, that's fine, but keep it somewhere else.Some Product Owners find there’s so much garbage in there that it’s easier to “cut over” to a fresh backlog. Others prefer to go through the old stuff and archive or delete what no longer makes sense. Whatever approach works for you is fine.The Product Backlog is the Product Owner’s strategy for how they will maximize the value of the product. It exists to help you think through what to do next. It contains a Product Goal so you can align the team around real value. It is not a garbage dump. When it gets too full of old junk, it just becomes confusing and loses its power.What a Strong Product Backlog Looks LikeIt has a clear, ambitious Product Goal so everyone knows what we’re shooting for.Items are ordered strategically (by value, risk, learning opportunity, stakeholder needs - whatever the Product Owner believes will deliver the most value)Most items describe outcomes, not just features.It’s regularly refined, but the Product Owner owns the content and ordering, even while they are requesting feedback from Developers and Stakeholders on sizing, order and content.It’s focused — not a graveyard of every idea anyone ever had.Higher ordered items are sized so that they can be completed within a single Sprint and contain enough information for the Developers to deliver them. The level of detail will vary based on organizational and team needs.The amount of "ready" work in the Product Backlog will depend on your needs. If you are in a rapidly evolving environment or have high trust from the organization, you do not need a high volume of "ready" work in the Product Backlog. Practical AdviceStart every refinement meeting by reminding everyone of the Product Goal.Ruthlessly archive or delete anything that doesn’t serve that goal right now.Focus on outcomes - do you really need that thing, or is it a distraction?Use your Sprint Reviews to inspect whether the work you’re doing is actually moving the product forward which means that you should measure customer outcomes and look at the results of the work that you are doing. Use input from the Sprint Review to update your Product Backlog. Your Product Backlog is one of the most powerful tools you have as a Product Owner. Don’t waste it by turning it into a glorified to-do list or historical archive. Treat it like the strategic plan it’s meant to be.For more on Product Backlog Management, signup for Rebel Scrum's one-day Professional Scrum Product Backlog Management class or the two-day Professional Scrum Product Owner class.