Hi, I'm Alena, I joined the Orion Flows Product team 9 months ago in my first role as Product Manager and I'd like to share our story with you.
Team: "So, what are we doing?" 4 faces expectantly looked at me.
Me: "Errrrrr, I guess we look at some tickets?”
Hastily trying to share my screen.
“Hang on, they're pretty much empty. What's this one about?"
Team: "Don't remember."
Well, there's no other way to put it, our first refinement together was a shambles. "Off to a great start," I thought, and realised we've got a lot of work ahead of us.
The team was fairly new and they didn't have a full time dedicated product manager before I joined so there wasn't much in terms of structure. I sat down with one of the engineers and we went through every ticket on the backlog, one by one, adding details so we could better understand what they're about and deleting the ones that were not needed anymore as they have become obsolete and didn’t support our goals. Later we agreed a definition of ready (ready to start working on something) and created a ticket template to make sure we include a clear description with acceptance criteria and capture any assumptions and risks.
Once we got the backlog sorted, we moved onto estimations. This wasn't an easy one to sell, some team members had a negative experience with estimations in the past when they were held accountable for them and measured against other teams. I assured the guys this would not be the case, the estimates would be for internal purposes only, purely to get a better idea of how much effort each piece of work involves to help me with planning. We started with t-shirt sizing which was far better than nothing and definitely helped with predictability but it was still kind of vague, and a few weeks later we eventually transferred to story points (I still consider this a personal highlight when the engineer who was initially dead against any estimations whatsoever suggested we give story pointing a go). This has allowed us to start measuring our velocity and identify where we can improve.
To start with, our velocity was a bit all over the place. In order to help stabilize it, we agreed on a set of reference stories and their respective estimations, e.g. this one is an example 3 pointer, that one is a classic 5 pointer etc. and we gradually started to see the difference. Although we’re much better at estimating now, we can never be 100% precise, they are just estimates after all and there’s always uncertainty in software development, but having a point of reference and particularly breaking the stories into smaller chunks made it easier to be closer to reality (most of the time :) ).
Another thing that hugely benefited our predictability and overall quality of work is the very simple yet very impactful concept of an ‘epic leader’. It is what it says on the tin; each epic or feature has a designated epic leader, which is basically one of the engineers on the team taking a lead on that piece of work. They’ll be involved from early stage discovery to completion, they’ll gather information, join any meetings relating to the topic, break the work down into stories and do initial refinement. Introducing this concept not only resulted in much more productive team refinement sessions, but it also gave engineers more ownership, empowerment and autonomy. Having tickets better refined, broken down and estimated significantly improved our capability to plan more accurately; we now mostly stay within the desired range of completing 80-120% of what we planned for the sprint (as opposed to 50-90% a few months ago) and our average cycle time went down from 5 to 3 days.
I didn’t achieve this all on my own though. To steal a quote from J.K.Rowling, help will always be given at Hogwarts at OVO to those who ask for it. Thanks to the amazing mentoring from Rebecca Gray and Rich Purkiss, I was able to take the learning of others to enhance my own personal development to the team's advantage. I wanted to experiment to see what worked for us, so with Rebecca and Rich’s guidance we tried the cost of delay technique, made improvements to our first line support, got better at splitting stories, successfully implemented the epic leader concept, did our first user research and in the end even put together a strategy document!
None of the changes I mentioned throughout this post were groundbreaking, but together the value accumulated to transform a team who has just about started working in iterations to one with increased throughput and a significantly more predictable velocity. Adopting new ways of working doesn't happen overnight and always takes time but I found that the key to success was implementing the changes step by step in small increments, evaluating what impact they had and binning the ones that didn’t work for us (like our ‘five minute feedback’ experiment for example, it was just too awkward).
Our refinement session last week was a testament to the transformation we’ve gone through as a team.
Me: "We’re nearly done with the SLO work so let’s have a look at refining the load testing tickets today."
Load testing epic leader immediately takes over, shares his screen to show the tickets and goes on to explain the background
“Ok, the first ticket is to set up a dedicated environment. We need this because… and the idea is to...”
Looking at the ticket I can see acceptance criteria is filled out, dependencies resolved, assumptions and risks highlighted, workflow drafted… I can just sit back, relax and let the team talk among themselves. Bliss.
To conclude, I'm still fairly new to product management so I'm definitely no expert but if anyone asked for my advice it would be this:
- Don’t be afraid to try new things
- Be patient
- Build on the experience of others (aka get a mentor)
- Measure impact and progress
And I'm not saying we have everything figured out, we're nowhere near the end of the journey (does it ever end?) but I'm definitely enjoying the ride.
___________
Thanks to James Hargreaves for having faith in me and giving me a chance to have a go at my first PM role, to Georgie Hopkinson for expertly coaching me and the team, to Gav Wade for always nudging me in the right direction, to Rebecca Gray and Rich Purkiss for their time and invaluable advice and, last but not least, to the awesome bunch on my team who are always open to experimentation and happy to try new ways of working.