Having provided a brief overview of my Agile journey, I thought that I would take a closer look at my introduction to software development and my role as a Product Owner.
Although I was aware that an IT project had started in order to bring the processing of the data I analysed in-house, I had not been involved in any of the initial sessions where the first steps were taken to create the Product Backlog or plan the first Sprint. My first involvement in the project was as a proxy for my line manager as he was unable to attend a retrospective and planning session at the end of Sprint 3.
During the retrospective, I was asked what had gone well during the previous Sprint and what could be improved. Having not been closely involved up until this point, I had little to contribute, but it was interesting hearing what the Development Team thought about their progress, the things that were impeding them and how as a team, with the help of the Scrum Master, they would approach removing those impediments during the next Sprint.
They moved onto the planning session and I was thrown a set of planning poker cards. The priority user stories had already been identified and I was asked to provide an overview of what was required, before being given the task selecting a card with a number on it from the Fibonacci scale and turning it over on the count of three. Needless to say the number I selected did not match anything that the developers or tester turned over, although it was interesting to see that there were difference in the sizes suggested by the members of the Development Team. They then discussed the user story further highlighting why they had selected their number, before re-sizing to try and come to a consensus.
Over the course of the following weeks I began attending more sessions on behalf of my line manager to help break epics into user stories, adding acceptance criteria to backlog items, estimating the size of the backlog and then re-prioritising it to ensure that the required features were available for the planned release dates. As I continued in the proxy Product Owner role attending more meetings than my line manager, it became apparent that a change of Product Owner was required and I was asked if I want to take on the role of Product Owner to which I agreed.
Initially I worked with the Scrum Master to ensure that the Product Backlog was prioritised and with the Development Team to ensure they understood what was required, updating acceptance criteria as necessary. However, in those early weeks it was more people coming to me to ask questions, rather than me being prepared upfront. At this time you would say I was a passenger in the development car, with the Scrum Master and Development Team taking turns to drive.
As I started to grow into the role I spoke with Development Team to identify what was required from me. I was advised that the Product Owner should be the driver of the car. Through their prioritisation of the Product Backlog, the Product Owner sets the direction of the development and at the end of each Sprint they have an opportunity to change direction if they want to, as if at a development crossroads.
In order to get my hands on the steering wheel, I took over the demonstration during each Sprint Review. Initially the demonstration of completed and accepted user stories had been delivered by one of the Development Team. Not only did this get me working closer with the team, it also enabled the Development Team to see how the system that they had developed was navigated by a user, enabling UI/UX enhancements to be added to the Product Backlog. I also began working more closely with the Scrum Master on the prioritisation of the Product Backlog in preparation for Sprint Planning as well as reviewing the estimated content of upcoming releases.
About 5 months into my time as a Product Owner, I attended a Certified Scrum Product Owner (CSPO) course. This was the best course I have been on (to date) and would highly recommend anyone taking on a Product Owner role to attend. This course helped me to better understand the processes that we were following, why they were happening and the benefits of having them. This enabled me to review how I had been undertaking the role of Product Owner, identifying some things that I was doing well, but also some areas in which I could improve. One area that I identified for improvement was the idea of a Product Backlog refinement session.
I took this idea and scheduled a one hour mid-Sprint session to walk the Development Team through the upcoming user stories. This gave the Development Team greater visibility of the Product Backlog items that they were likely to work on next Sprint and ask questions around the content of the user story/acceptance criteria. As Product Owner I was able to answer these questions or update the user story prior to the Sprint Planning session. By holding this on hour session, I was able to cut three hours off the Sprint Planning meeting.
At around the same time I started attending project board meetings and providing updates on progress and estimated delivery forecasts. It was at this time that I feel that had taken full control of the car and was driving the development forward.
Up until this point all of the development was completed with an internal Development Team – this was soon to change. Following our second release, the development transitioned to an external Development Team. This posed a number of new challenges and obstacles that, as the driver of the development, I needed to help navigate.
Next time, I will provide answers to some FAQs regarding Product Backlog refinement sessions before looking at my time as a Product Owner working with an external Development Team.