Basics of Product Ownership

Is your Scrum Team stumbling through Sprints? Are there a lot of carryovers or long discussions during your Daily Stand-up to clarify Backlog Items? Well, perhaps it may be time to revisit how Product Ownership is being carried out.

With over 6 years of experience overseeing cross-functional Scrum Teams, or Dream Teams as we like to call ourselves, I have a passion for Agile Coaching. Let me outline some key artifacts that may need to be revisited by everyone to ensure that there is alignment and momentum, as Scrum intended.

The Product Goal is the most rudimentary artifact and a key building block of any product delivery. This can be in the format of a vision statement. The intended end-user should be defined with high-level benefits outlined to showcase the total value being provided. Everything else falls into place after, whether it’s a roadmap or user persona(s).

Once the above is in place the Product Backlog can began to take shape. It is a living document that captures what needs to be done and when, through clear description and a ranked list. Each item should be able to be completed in a single Sprint. If it will take longer, it needs to be broken down. If it will take further research, the prerequisites can be tackled seperately or ahead of time to ensure it can fit in one Sprint. It is important to note that the Product Owner represents other stakeholders, and their decision represents the combined needs of those who benefit from the product. The Product Owner therefore has the final say on the Backlog, but should be open to negotiating if the Scrum Team brings up a valid case. Most importantly, the Product Owner defines the intended outcome (i.e. what) and the Developers should outline the path (i.e. how)

Once items are ordered, a Sprint Backlog can be created by the Developers. This is the next most valuable set of deliverables. The Sprint Backlog is also a living document that consists of the Sprint Goal, planned Backlog Items, and daily updates of the Scrum Team on their progress. This is the latest and greatest development on the product.

To wrap up the Sprint Backlog, each Backlog Item needs to be validated through a Definition of Done. If your organization doesn’t have a set description, at a minimum, a Definition of Done should exist for your product. Perhaps your Scrum Team will or is delivering hundreds of Backlog Items, how will you know when one is finished versus the other? How will you objectively assess different deliverables? That’s where the Definition of Done comes in to set a clear standard on when a Backlog Item can be set to done. The Definition of Done should be created by the entire Scrum Team, so that everyone is on the same page. Typically, my Definition of Done has been in the form of a checklist to include design, development, and testing criteria for validation. There are also Definition of Ready and Definition of Entry to thoroughly vet Backlog Items, I will cover these topics in a future article.

No matter your role in the team, understanding the vision of the product is the foundation of the delivery. Sometimes to be Agile, you need to take a moment to stop and assess before continuing further. It may sound counterintuitive, but it will save you a lot of pain in the future. If you’d like to read and learn more for yourself, I highly recommend revisiting The Scrum Guide and reflecting on your Scrum Team.

Thanks for reading. Connect with me.