If some consider Scrum as an Agile project management framework, many people consider that is is more a product management approach. Anyway, Scrum is about understanding the need of the customers to deliver value. In this context, the concept of “personas” can be used to support user-centered design throughout a product development cycle by focusing on the characteristics of key user segments.
The product owner role is responsible that the production of the Scrum team meets the requirements of the customers and deliver value for the organization. This is an important role that requires specific skills. But how do you know that your are doing well? The Growing Agile team as created a self-assessment for product owners.
In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items.
As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common questions: What do Product Owners really do? Do we even need Product Owners?
This is a talk about how shifting the focus from craft to product has affected my company. Our delivery teams are required everyday to make trade offs between what would the best technical solution and the one that is right for the product they are delivering. Ultimately, we get paid to solve business problems, not to be perfectionists.
Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos. Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed product backlogs.
Running an experiment is trivial: Make a change and see what happens. Running experiments at scale, however, is a different story. It is not trivial to simultaneously run hundreds of experiments across 100 million users. It’s not trivial to cover dozens of platforms and markets while staying on top of the technical and methodological complexities.
Scrum Expert Copyright © 2009-2024 Martinig & Associates