Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In this energizing 38th hands-on Agile session, Roman Pichler delves into your questions on the role of the product owner. The topics range from product manager vs. product owner vs. business analyst to the right size of a product backlog to linking product vision to product goal and sprint goal.
During the session, Roman addresses the following questions:
Scrum is a tactical framework to build products, provided you identify what is worth making in advance. But even after a successful product discovery phase, you may struggle to create the right thing in the right way if your Product Backlog is not up to the job — garbage in, garbage out. The following article points to 27 common Product Backlog anti-patterns — including the Product Backlog refinement process — limiting your Scrum team’s success.
First of all, let’s have a look at the current edition of the Scrum Guide on the purpose of the Product Backlog:
More and more software development teams are switching from the traditional Waterfall approach to Agile project management. Agile helps teams to become more flexible and adaptive which is essential for staying competitive in today’s business environment where customer needs are constantly changing and evolving. But what exactly do we mean by being “more flexible and adaptive?”
Let’s imagine a team that is working on a software product. The product is going to be released in several versions, and the Product Manager creates a roadmap to plan the timeline for these releases (please see the picture below). Each release itself can be broken down into smaller chunks of work that are usually called product increments and form a Sprint (typically 2-4 weeks long).
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. The Developers Code Fallacy starts with the idea that Developers are rare and expensive and should focus on creating code. Business analysts or customer care agents can talk to customers instead. However, in practice, it has a diminishing effect on a Scrum team’s productivity and creativity. It is a sign for an organization still profoundly stuck in industrial paradigm thinking.
Join me and explore the reasons and the consequences of this Scrum anti-pattern in 110 seconds.
Contrary to popular belief, the Scrum Master success principles are tangible, when we guide the analysis with an outside perspective.
Read on and discover four Scrum Master success principles, from when not to use Scrum to product quality to supporting the Product Owner to putting self-management at the center.
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.
Garbage in, garbage out. No matter whether your team chose Scrum for the right purpose (solving complex, adaptive problems), whether your 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 the perception of your Scrum Team around among stakeholders and customers.
How to make Scrum work? Read on to learn more about my top three objectives for Scrum Masters striving to achieve Scrum Mastery.
You may also like: Scrum 101: Everything You Need To Know
In simple terms, a product backlog is a list of everything that needs to be done in relation to the product. This is the key artifact that helps in translating the high-level product vision and serves as the foundation to initiate the development of the product.
The product backlog includes features to be built, enhancements, fixes, quality attributes, etc. in the form of user stories.
This is beneficial in comparison to the waterfall approach of creating multiple pages of requirement documents because it provides prioritization so that the team has a direction, has the necessary details required by the team, and it keeps evolving and responds to change.
This is the fourth and final part of the Scrum Deconstruction. You can find part 1 here, part 2 here and part 3 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org's PSM I exam that I took back in October 2017. I have made updates based on the newest version of the Scrum Guide, November 2017.
Here I share in the hope that someone finds it useful.