July 07, 2023
Get in touch
The world of software development has undergone significant changes in recent years. For a long time, software development projects were carried out according to a predetermined plan, with each phase meticulously planned and documented ("waterfall principle"). However, for some time now, a different approach has been established: agile software development.
In agile software development, teams are usually self-organized and interdisciplinary. The exact composition can vary depending on the project and company, but typically an agile development team includes members from different disciplines such as developers, designers, testers and other relevant roles. The team works closely together to achieve project goals and deliver high-quality software solutions.
Product owners play an important role in agile development teams. They are responsible for managing the product backlog and tasked with achieving the desired outcomes of the development team. This role was introduced as part of the Scrum framework to solve challenges in direction and prioritization of product requirements.
Stefanie Kohlen is a Product Owner at AOE. During her years of press work for clients in the ITC sector, she discovered her passion for digital projects. In 2007, she transitioned to project management at an online agency in Düsseldorf and began extensively exploring Scrum and agile methodologies starting from 2014. Since then, she has been working as a certified Product Owner in various projects, including scaled ones, constantly striving to improve the work processes for both the team and clients.
In general, the role of the product owner is often described with the term value maximizer. As a product owner, I am responsible for the vision of the product and what is implemented when. The product backlog, in which all tasks are collected and managed by me, is of central importance. They are prioritized by importance, value to the product and level of their current development. In order to achieve this clear elaboration, the product owner is in constant contact with the customer or stakeholders. I define the requirements together with you and transfer them to the backlog in a way that the team can understand. The focus here is on professionalism. Every product owner should develop a good understanding of their domain.
The product owner is responsible for the user stories, which are later implemented by the development team. However, he does not necessarily have to write them himself, but can also delegate this task. From my experience, this can make sense if it is not a purely functional but rather a technical requirement. These can be improvements but also the reduction of technical debt. It is important to discuss this with the team and prioritize these things in the product backlog. Possible questions: What happens if we don't do this?
... I ensure that I receive all necessary information about the user stories I have prioritized. Are all acceptance criteria included from my perspective? Is the story clearly described, meaning are the goal, customer group, and action clear? Are dependencies on other teams and systems transparent and communicated? Often, such points are also clarified with the architect or business analyst. Nevertheless, I have had good experiences with discussing the story in advance with someone from the team. Because different roles have different perspectives and require different information. For me, the priority is that the user stories are as comprehensive and clear as possible to achieve the goal of the backlog refinement.
Before the backlog refinement, I inform the team about which user stories I would like to discuss with them. This way, they can familiarize themselves with the topics and prepare any questions and comments in advance.
In the backlog refinement, I present the user stories to the team again in a rough manner, and ideally, we reach a shared understanding and estimation of the story. The perspective of the different roles in the team is especially valuable here because they contribute to completing the story. Have we captured all the acceptance criteria, both functional and non-functional? Does it help us achieve our goal? Are there any technical constraints that make our idea more challenging? Are there still open questions that need to be clarified? Or is the realization so difficult to estimate that we need to dive deeper into the matter through a spike to gain more clarity for implementation? For me, the team's collaborative exchange is the most crucial aspect of the work because it brings together all the skills and leads to the most valuable outcome.
Already before the sprint planning, I thoroughly engage with the current and upcoming sprint. Because besides prioritizing and implementing stories with the highest value, there are also a few contextual factors that are important during planning. It mainly involves clarifying the velocity for the next sprint. Will we be able to complete all user stories from the current sprint, or might there be a possibility of "spillover"? In theory, that ideally shouldn't be the case, but we all know that practice can be different: user stories can turn out to be larger than initially anticipated, external circumstances can act as blockers in a story, and sometimes people might be unavailable. I need to consider all of these factors when roughly planning the new sprint as the product owner before the sprint planning.
During the planning itself, I review the current sprint with the team to make any potentially spillover tasks transparent. Then we collectively examine the pre-planning for the upcoming sprint. If there have been any changes to the stories that have already been refined, we take another look together and re-estimate if necessary. Once we've done that, I ask the team if the sprint works for them. If everyone gives a thumbs up, it's good; otherwise, we discuss concerns again and make adjustments accordingly. After that, we collaboratively formulate a concise and, if possible, humorous sprint goal that guides everyone in terms of what we want to achieve with the sprint. The second part of the planning belongs to the development team. Here, they delve into the task breakdown of individual stories and create the necessary to-dos to implement the story. In most cases, I, as the product owner, remain present to address any questions that may arise.
The daily scrum primarily serves the team to exchange information about what tasks were completed from the planned to-do list each person set for the previous day and what the plan is for the current day. However, it is also an opportunity to address and ideally resolve any blockers, impediments, or other current events. As a product owner, I am present more as a silent participant and provide answers to questions or insights into news related to the project and/or the team.
During the ongoing sprint, my tasks as a Product Owner are diverse. On the one hand, I naturally focus on the current sprint. I am available to the team for any questions and clarifications. Additionally, I keep an eye on the progress of the sprint. It can happen that things are completed faster, and there is the option to pull in stories. I review completed stories in the so-called PO Review together with the tester and either accept them or leave comments.
The remaining time is dedicated to the backlog, its items, and their prioritization. The goal here is to make the upcoming stories "mature," gather all necessary information, and actively engage with stakeholders as well as the team.
The Sprint Review belongs to the team. Here, they present the implemented stories to the stakeholders and showcase the results of the sprint. For me, the feedback from the stakeholders is especially important here. Do they have any comments or suggestions? I then take these things back to the backlog and prioritize them accordingly.
The Sprint Retrospective is designed to take a look back at the sprint. What went well, where were there obstacles? I already think about these points in advance to be prepared for the retrospective.
Openness and trust within the team are important here. Everything that caught one's attention and weighs on the mind should be addressed. After all, it is our collective ambition to continuously learn, improve ourselves, and eliminate impediments of all kinds. Often, concrete measures are defined, which various team members take as tasks until the next retrospective.
This article is part of a series in which we highlight the different roles in agile software development. Be sure to check them out!
