Product owner for a day

July 4, 2014

IMG_3333Recently, I participated in an experiment for Product Development. It was during a weekend, in the mountains, with a team of 8 persons from Bucharest Agile Software Meetup Group. We didn’t know each other very well and we have not been working together before. Our misson was to develop a product in a day and a half. We chose to implement the well known board game, PowerGrid. It was a great experiment and I have learned a lot. Here are some key take aways:

  • understand well ahead what you want to build (the product)
  • establish a unique and clear vision of what is to be delivered for the whole team
  • know your responsabilities and do them first
  • communicate constantly with the team
  • make things visible

The preparation

We had a plan. We prepared the development environment before. We had a project skeleton, git repository and continous integration in place. We chose to use Scrum with one hour iterations. For making the work visible to the team we created a virtual board with some user stories to start with. We made the reservations and we left on Friday in the afternoon. At dinner, we assigned the roles in the team. I got to play the product owner role. After dinner, we played the game in order for all of us to know it and to have the same vision of our product.

My plan as a product owner

Saturday morning at 10 o’clock we started. While the development team was busy with preparing their environment for development, I started to prepare the stories for the first sprint. I had to move fast, because the development was starting soon and I was not ready. I wanted to organize my job for the whole day as follows:

Before first development sprint:

  • to chose a functional flow to be implemented during the whole day
  • to split the functional flow into features
  • to schedule each feature for a certain sprint
  • to present the flow with the features to the team before first sprint

Before each development sprint:

  • to split each feature into clear user stories
  • to present the user stories to the team

The outcome of my plan

functionalFlowThe first development sprint was beginning soon and I was running out of time. So, I just picked some stories from the virtual board and put them on a functional flow. Big mistake. I should have picked the flow first. To make things worst, I didn’t know those stories in detail because before Friday night I did not know how to play the game. I was a newly “hired” product owner. firstSprintThe first sprint I was lucky because the feature was easy and we reserved some time to discuss the stories. Second sprint came with few missunderstandings regarding the user interface experience and in the following sprints we even implemented “Resources market” story wrong because of incomplete user interface experience requirements. We had a functional flow to follow, but we did not have the user interface mockup for it or any other neccessary UIX details. Because of this, I had to move around from one team member to another and respond to their questions. It was wrong to do it like this. Each developer knew how his story was implemented but he did not know how it will integrate with the others’ user stories. I was leading the team in delivering a broken user interface.

What I did wrong

  • I did not know the product in advance
  • I did not have an established flow to be delivered at the end of the day
  • I did not focus on UIX details and the user stories were not clear
  • I did not set acceptance tests for each story
  • I was just briefly presenting the next user stories to the team

I was over confident on my ability to write user stories and acceptance tests. Also, we were all technical people in the team and I relied on being easy to communicate and understand each other. But the above facts have proven that I was mistaken. Writing user stories and communicating them to the team is not enough for being a good product owner. The outcome of my plan would have been different if I would have followed the basic responsibilities bellow:

  • The user stories have to be very clear
  • Acceptance tests for each user story have to be defined
  • The user stories and the corresponding acceptance tests have to perfectly integrate in the same functional flow
  • How the integration is done must be fully understood by the whole team

Lessons learned

Is not easy to be a product owner. It is a full time job which requires special skills and training. Once I wrote a blog post about the product owner seen by a developer, but there I have presented my view of the role based on my work experience as a developer in an agile team. Now I know that my view covers only a part of what a product owner should know and do. Therefore, I want to know more about it. I have started with a short definition and I will continue with other resources recommended by my colleques. I also intend to participate in a training course this autumn. In this way, at the next Product Development experience I will know how to build a better product backlog and I will lead the team in delivering the most valuable features.

Categorised in: , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *