There are plenty of Product Owner failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone.
Explore with me three widespread examples of how Product Owners fail their team in three short video clips, totaling 6 minutes and 9 seconds.
A few weeks, Scrum.org hosted a webinar on Product Backlog anti-patterns with me, which left several questions unanswered as we ran out of time. Hence please find following my answers to the additional 18 questions I could not answer during the webinar Product Backlog anti-patterns Q&A session.
Garbage in, garbage out: No matter whether your team chose Scrum for the right purpose—solving complex, adaptive problems. No matter whether your Scrum Team’s product quality is top-notch or whether your teammates embrace self-management to the fullest. If your Product Backlog is not up to the job, all of these accomplishments will account for little, as your team will provide less value to its customers than possible. Here is where the forensic Product Backlog analysis steps in, a light-weight, simple practice to help Product Owners and Scrum Masters unearth anti-patterns that led to your low-value Product Backlog.
Learn more on how a piece of paper and a pencil can turn around the perception of your Scrum Team among stakeholders and customers.
The fourth Liberating Structures for Scrum meetup addressed the Product Backlog, more precisely the issues with Product Backlogs that subsequently cause Sprint Plannings to fail and Scrum Teams to deliver below their capabilities; as the saying goes: garbage in, garbage out.
The third Hands-on Agile webinar product backlog anti-patterns covers common problems from out-dated and oversized tickets to the part-time proxy product owner and his or her idea repository. Learn more about the numerous product backlog anti-patterns that can manifest themselves when you try to create value for your customers and your organization.
Where to start when kicking-off an agile transition?
Usually, tools and processes are smallest the common denominator among all participants, as they are at the core of the grand scheme of agile things.
It is a rare occasion that you start from scratch with a brand-new team without an existing product, probably even in a more or less nascent organization, for example, a startup.
In most cases, an existing product delivery organization with available products, and services will go “agile“. In this case, turning attention to the available product backlog is a pragmatic first step. The following process describes what aspects need to be attended to optimize the outcome.
