Being a Product Owner in Warehouse System Team
As an additional task in my career as a project manager, I had the chance to experience being a product owner. While everyone was discussing the applicability of product ownership for system teams, the subject of ‘being a product owner in the warehouse system team’ was added to my adventure. In this article, I will tell you about an experience outside of the mold.
I want to sit on the conveyor belt…
While Trendyol continues to serve as an online platform, an operation and R&D center grows day by day in the background. What does the system team do in these centers where the number of packages per minute is important? What are their responsibilities? First, let’s get to know the warehouse system team.
Warehouse system team;
“ Installs and manages the infrastructure and system at the operations centers.
“ Provides personal inventories of employees and provides full support.
“ Sets up all inventories used in operation and provides 24x7 support.
“ Supports system teams in patch management and server installation processes.
On my part, there is no definitive backlog prepared months ago, no releases, no concrete product. So then I can hear you saying why the product owner exists. Because as it is briefly mentioned in the scrum guide, ‘The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.’.
But we, as Trendyol Technology Team, like to break the established patterns. And, we left behind the discussions about whether this is an operation, a project, or a product and focused on managing the processes in the most effective way.
No more comfort zone…
As a product owner, I will briefly talk about what I do with the team.
I am making a roadmap for the growth strategy of the logistics infrastructure.
I am preparing a backlog for the projects in the roadmap. I feed the weekly sprints with this backlog.
We review the backlogs with the team in Sprint Review.
I follow daily updates with daily standups and support the team to overcome obstacles.
We do one Retrospective and one Continuous Improvement Session every two weeks and create improvement points and in-house projects.
So far everything is as predicted. Although the Agile mindset is always adapted to software teams, we tried to adapt it to system teams. The thing that basically affects my flow is that the teams I work with are warehouse operations teams.
Continuity and speed are very important for operations teams. Very fast action is expected in case of a problem or request. An improvement idea from here is usually prioritized. For this reason, the system team’s backlog may fill up suddenly. Ps: Welcome new challenge!
At this point, we considered all the services we provide to the operation teams as a single product. We have determined our goal to provide and develop that service in the best way possible. But the product backlog has turned into a more complex structure. Together with the team, we stabilized this complex structure after an observation period. So how did we do this?
Basically, I split our weekly workload into planned and unplanned items. I will talk about that wonderful world where there are only planned items.
What a wonderful world…
At the beginning of each quarter, by sharing our roadmaps, we can plan items such as opening a new warehouse, switching to new technology, expanding the current operation area in the relevant time intervals. We come together with the Software, Opex, and Warehouse operation teams every week to keep our communication dynamic and update the projects. In this way, we can analyze the systems we will support and create our backlog items. Everything is fine..
Realism is not just an art concept…
And yes, what we couldn’t plan. The combination of planned items and sudden demands is a bad but possible scenario. Our main problem here was that the team did not overload. In the first step, we needed to measure the team’s work weekly. So we started by calculating the score of the sprint we ran weekly.
We scored the items we took from the backlog to the sprint, according to their complexity, based on the numbers in the Fibonacci series. Then, we discussed the items until every member of the team agreed. As our scoring practice increased, so did our scoring standards. While making this scoring, we used the backlog items we took from the Gitlab board to the sprint and the StoryPoint plugin on Slack. This integration saved us time during the planning and enabled us to discuss items that we thought differently in scoring asynchronously.
As a result of the score, we observed that we always did a similar amount of work for three weeks. In this way, we reached an average sprint score. After planning, we added the unplanned label to all the items that came to the team and took them into the sprint. We accepted the ratio of incoming unplanned items to the sprint’s total score as a reference value. While planning, we tried to get items from the reference value to the total sprint score. In this way, the team was able to respond to incoming requests in the fastest way without overloading in sprints.
Unplanned items are not preferred by either the team or the product owner. For this reason, we also include unplanned items that come in the development meetings we hold once every two weeks. We are talking about the unplanned items we receive and automating our operational processes. Thus, we create new items for the backlog of our product, which we see as an operational service.
By completing the items we created with the Improvement label in our sprints, we aim not to encounter unplanned items at the end of the day. Therefore, I can say that we are doing well for now…
