My Notes on being a Product Owner (so far)

I was recently asked for advice by a someone who was new to the role of being a Product Owner. I decided to write something down which I would be able to share in the hope that others might find this useful. I’ve tried to distill what I’ve learned in my three years of doing the job into these notes.

This is quite Skyscanner-focussed and uses terminology such as tribes, squad, guilds etc which come from the Spotify Model.

This advice is based on my three years as a Product Owner in Skyscanner.  They touch on the more textbook Agile responsibilities of being a PO as well as my own personal advice on how to perform them. They might not be completely ‘textbook’ but they’ve served me well so far and if I’m still doing this job in a few years, I’ll be confident in their accuracy!

Be the voice of the customer

Product Owner Manual page 1.  You need to be the voice of the customer to your squad which means you need to be aware of who your customers are and how they use your product. You need to understand their problems and their pain points. You need to know how removing certain reliability issues or building new features will improve their life.  I like to think about the Modern Agile principle of Make People Awesome.  How can we make our customers feel awesome?

This is a real balancing act because you’ll need to juggle their immediate wants with goal work and service ownership, but these asks should ultimately find their way onto a roadmap if they’re important enough.

One piece of advice I’d give on getting to know your customers is to try to find out the guilds they might be part of and attend the meetings and join their Slack channels if they are public. Sometimes the chat might feel like it’s going over your head but ask questions and even though it might not feel like it, you are building out your knowledge base.

Similar to being the voice of the customer, you need to flip that perspective around and be the voice of your squad to the business. Some of this will happen as a matter of fact such as attending governance meetings, but you should also look to celebrate successes publicly whenever you can.  Encourage blog writing within the squad and lead by example if you need to.  Speak with Tribe Leads and try to find ways of doing demos at All Hands etc.  It may seem pretty daunting but it’s part of the job.

Grooming and Backlog Prioritisation

You should set up regular grooming sessions with the squad and do this collectively but ultimately the decision on what to cut and what to prioritise rests with you.

This is my approach to grooming/prioritisation;

The sprint backlog(s) should ideally contain three sprint placeholders for Now, Next, Later with the current sprint being at the top and most detailed. Below that, the next sprint(s) would ideally be starting to take shape. 

These cards should be prioritised based on;

  • Dependency – do we need to build a cluster etc before development work can happen. Are we able to measure metrics? 
  • Customer Priority/Impact – it goes without saying we want to work on the highest impact tickets first
  • Riskiness – work through risky work as early as possible. Fail Fast/Learn Fast.  It’s soul destroying getting 6 weeks into a piece of work then realise you’ve hit a dead end.

Keep your Next sprint pretty loose to accommodate rollover cards from the current sprint, technical blockers or changes in customer demands. If you can see more sprints after Next taking shape, by all means create them but don’t get too hung up if you can’t – you’ve still got a few sprint planning meetings to happen before this sprint takes place.

Involve your team

Involve your team in customer discussions.  This is hugely beneficial for a number of reasons;

  • The stereotypical role of the PO is to be the go-to person between a customer and the dev team, and be the single wringable neck. This by definition makes you a bottleneck. Don’t be a bottleneck – involve others.
  • Your understanding of the problem might be flawed, ergo when you communicate this to your team, their understanding becomes flawed.
  • You might not understand a technical requirement that the customer has.  Your team consisting of subject matter experts will probably be able to help you in your understanding, therefore it makes sense to involve some of them.

I get frustrated when I read about the stereotypical introverted software engineer that just wants to be coding in a dark room.

Every development team I’ve ever been in had engineers who wanted to know that their efforts were impactful and not a waste of time and craved face-to-face time with customers.

Setting the Vision

One of your responsibilities as PO will be to set the vision at some level – Tribe/Squad etc. A piece of advice I’d give is to really communicate the problem space to your squad then let them decide on how they want to tackle it rather than telling them what to do.  This helps give your squad autonomy but it’s up to you to ensure alignment.  Your storytelling ability (more on that later) will help you with this. 

It’s a bit of a cliché but sell the problem, not the solution.

Foster Alignment to the Vision

To help foster alignment within your squad, I’d recommend having semi-regular roadmap meetings with your squad. I’ve found fortnightly is about right. In these meetings, chat about how your current goal is going.  Is it faster/slower than you all thought and why might this be the case? Use this to get a feel for the key milestones you want to deliver over the next few weeks.  This helps get people on board with the shorter-term plans (and also negates the need for sprint pre-planning which some squads do).

You should also look at the longer-term roadmap and discuss if it’s still the same or are there new business priorities which might be looming in the next few months that we should be aware of now. The intention is that your squad would be able to give a clear answer on what they will be working on in two weeks from now, two months from now and potentially six months from now.

Arguably, more important than your ability to deliver in these PO responsibilities is your relationship with your squad.  Bear in mind the following;

Be a Servant Leader

You need to adopt a servant leader approach with your squad.  Ultimately your success as a Product Owner is dependent on the success of the team. Be subservient to your team and do all you can to remove blockers and build knowledge.  This siding with the squad can take a bit of getting used to but stick with it.  Sometimes you’ll see a PM (and I’m stealing this for PO) being referred to as the ‘CEO of a product’ – this is completely false because as PM/PO, you have no authority over your team – it’s your job to inspire! It’s on you to make your squad get excited about building a solution that delivers value.

Additionally, your squad will contain subject matter experts and it would be folly not to utilise that knowledge.

Fight your Squad’s Corner

You’ll sometimes need to forcibly manage up the way and really fight your squad’s corner. This can be uncomfortable at first but you’ll get used to it.  Skyscanner values say it as it is as part of its culture.  For example, if you’re given an unrealistic deadline, don’t accept it and push it down to your team with a shrug of the shoulders saying ‘it’s what management wanted’.

Don’t be a Shit-Shield

Don’t be a shit-shield for your squad.  Lots of people when I started as PO told me the number one thing to do was protect my squad and let them concentrate on building.  It seems pretty sound advice until the time comes when there’s a general feeling that your squad is under-delivering and you’re not communicating that to your squad.  Then you take a holiday and can’t control the narrative. Through second hand whispers and rumours, the full extent of bad feeling is communicated in one go and it’s a real shock to the system.  The squad will feel bad as their professional pride takes a knock and you’ll have egg on your face for not being honest and transparent.

Be more like a shit-sieve.  Filter out the worst bits but make sure the overall message gets through.  Your squad needs to know what’s going on around them, so distil any feedback and use it to your advantage to provoke a positive reaction if required.  If a difficult conversation needs to be had, have it.  It’s not fair on your squad to keep anything in the dark.  Always be as transparent as possible.  It makes it easier to relax on holiday!

Storytelling is Important

Learn to tell a story. Use this as your method of communication. 

Stewart Butterfield, the CEO and founder of Slack once said an interview with Reid Hoffman on the Masters at Scale podcast; 

If there was one piece of advice I wish I could phone back and give to myself was just concentrate on that storytelling part, on the convincing people. Because if you can’t do that, it doesn’t matter how good the product is. It doesn’t matter how good the idea was for the market, or what happens in the external factors if you don’t have the people believing.

So, when passing on a directive/piece of work etc to your squad, know the story behind it.  Understand the impact of a customer request, ie, building feature x will save customer y  z amount of hours each month to focus on growth rather than deciphering reports. Communicate this well to your squad and you’ll get the buy-in.  You may need to convince them this story is more important than the story they’re working on but that’s a healthy debate.  It’s better than you asking them to work on something that you’re not sure about yourself, which can create a lot of uncomfortable questions.

When you really understand a story and the importance of a request, you can use this to really zero in on working on the right thing.  I’ve actually been successful in pushing back on leadership requests in the past because the story they were telling me about a piece of work they wanted done wasn’t compelling enough for us to stop what we were working on.

The last two points I want to give some advice on relate to stakeholder management.

Be a Conduit

You need to become a conduit between your squad and tribe/goal leadership. There are certain communication and ways-of-working nuances that tribe and goal leads have which are different to the nuances that squads have.  As a PO you need to be able to translate these and ensure that the correct message is communicated to leads regarding squad delivery cadence, blockers etc and don’t be afraid of delivering bad news.  People don’t like bad news, but they hate bad news even more when it’s a last-minute surprise.

When tribe leads know what’s going at squad level and squads know what’s going on at tribe level, life is much better for all involved.  It’s the transparency and open communication that enables this.

Enjoy the Theatre!

Finally, one last point and one that I probably shouldn’t be making public is with regards to ceremonies you’ll be attending as PO such as governance. 

I’ve seen some people not feel particularly comfortable in these environments. My advice would be to try and enjoy them.  Treat it as a bit of theatre.  There’s nothing to worry about if you’ve got the answers to the difficult questions because you’ve done your homework and come well prepared.

Use these sessions to celebrate the success of your squad and to build your own personal brand!

Reading List

Here are some books that I’ve found useful.  They’re ordered by my purchase date on Amazon – not by any rating.

Ones that really stick out are though are Scrum Product Ownership: Balancing Value from the Inside Out,  Strategize, Escaping the Build Trap and Lean Analytics (which isn’t as dry as the title sounds).

I apologise in advance for the poor table formatting – Word Press is not one of my strengths.

TitleAuthor
Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Alistair Croll
The Coaching Habit: Say Less, Ask More & Change the Way You Lead ForeverMichael Bungay Stanier
Escaping the Build Trap: How Effective Product Management Creates Real ValueMelissa Perri
Validating Product Ideas: Through Lean User ResearchTomer Sharon
Impact Mapping: Making a big impact with software products and projectsGojko Adzic
Strategize: Product Strategy and Product Roadmap Practices for the Digital AgeRoman Pichler
The Art of Action: How Leaders Close the Gaps between Plans, Actions and ResultsStephen Bungay
Scrum Product Ownership: Balancing Value from the Inside OutRobert Galen
Collaboration Begins with You: Be a Silo BusterKen Blanchard
The Goal: A Process of Ongoing ImprovementEliyahu M. Goldratt

Small Batch Approach to Roadmaps

In this blog I’m going to discuss how that silver bullet of lean – small batches – can be, and should be used to build continuous improvement into your roadmap.

All the Services

I work in a platform tribe and a fact of life for platform teams is that they own a lot of services.  When the service ownership footprint is large, the potential for numerous fires to be burning increases.

With this in mind, our teams need to be able to juggle project work with ongoing service maintenance. Impact and flexibility are the keys to success.

At Skyscanner, we tend to refer to our projects as initiatives. For the purposes of this post, I’ll start with a definition of an initiative as described to me from a previous manager;

Our customer oriented and strategically aligned units of work

A previous manager

I’ve worked on a few of these initiatives now and seen some work very well and others not so much. There have been a few reasons for the difference but ultimately the biggest difference between a well-executed initiative and one not so well executed, in my experience, is down to the size of the scope of work which will in turn determine the length of commitment by a development team.

Keep it small

So why is a smaller initiative a good thing? Why should we limit scope in order to keep our batch small?

I’ve very crudely tried to illustrate this in the diagram below based on the delivery cadence of a squad I was part of earlier last year whereby our initiatives – not by design – ended up being very short in their execution;

So, what’s going on in this illustration?

Well, the x-axis simply represents the time taken for each initiative whilst the y-axis is the customer value being delivered.  The dotted line represents what I’ve termed ‘Required Customer Impact’ aka ‘Minimum Loveable Product’ (for those who keep up to date with Agile blogs).

To me, ‘Required Customer Impact’ is a point in an initiative where both the development team and customer are comfortable enough with the value that’s been delivered for now. Both parties can leave this project for a set period of time, focus on other work, but leaving a commitment in place to each other that future work will be undertaken to build on this first batch.

And the positives to working like this?

  • Shorter timescales mean that we were delivering value to customers quickly and often.
  • From a human perspective, engineers get to work on different, varied projects rather than being bogged down in the same area for months at a time
  • Shorter batches mean that you can see with better clarity what ‘good’ looks like at the end of your initiative and how you’ll get there.  Planning becomes easier and the potential for getting lost in the initiative is vastly reduced
  • Smaller batch sizes will increase quality.  This can manifest itself in a number of ways but one thing that I’ve noticed with smaller batches that code quality has increased and tech debt has reduced.
  • Short-sharp initiatives also help keep your roadmap flexible which allows you to adapt as circumstances and the business terrain change

It’s this last point about roadmap flexibility which is crucial when thinking about how the smaller batch initiative model can help enable continuous improvement.

A process is either slipping back or being improved, and the best and perhaps only way to prevent slipping back is to keep trying to move forward…

Mike Rother, Toyota Kata

In his book “Toyota Kata”, Mike Rother makes the point … a process is either slipping back or being improved, and the best and perhaps only way to prevent slipping back is to keep trying to move forward…

Therefore, if I’m a Product Owner of a squad responsible for between 5 and 10 services, it would be folly to build a roadmap that commits our squad to six months of work on one service to the detriment of the others.  Sure, we may delight a particular customer but at what cost to the customers of those other services that are now slipping backwards?

By only committing to smaller batch sizes which maybe only 4 to 8 weeks in length, we’re giving ourselves enough time to deliver ‘Required Customer Impact’ and then move onto our next service which might be needing some TLC.

Building the Bigger Stuff

Hopefully this seems fairly straightforward but to reinforce the point, let’s look at what the opposite of a short batch looks like.  What happens if you’re part of a team tasked with building a new Death Star?

Your diagram would look something like this;

The initiative hasn’t been broken up into smaller batches, and from a customer perspective, the time to ‘Required Customer Value’ feels like forever!

This isn’t Lean and not great for customers.

Let’s also look at this from a development team viewpoint. Morale will start to wane as the feeling of ‘when will this ever end’ creeps in. Engineers will become fatigued as stand-ups and retro’s take on the same themes over and over again, and they’ll be itching to move onto something else.

So, what’s the answer apart from not building Death Stars?

Well, sometimes it’s necessary to build a Death Star.  Big projects are never going away. From my own experience I can testify that Data Platforms weren’t built in a day.

What we can change is our approach to them. 

Think about the overall initative and the various customer value milestones that we’re trying to deliver over the course of the project.  Instead of trying to deliver them all at once, how can we deliver them in an iterative way?  How can we turn the above diagram into this one;

In reality this is easier said than done and requires a lot of input from both customers and your development team to ensure what you’re delivering is actually of real value, and that potential riskier technical gotcha’s are either taken care of or will be tackled early.

Show me your Roadmap

Now that we’ve broken our bigger project into smaller batches, how does then translate into a roadmap?

Remember, we’re not trying to build the Death Star in one go; we’re breaking it down to slot in with our other service concerns. In the end we might end up with a rough 6-month roadmap looking something like this;

  • We’ve built v0.1 of our shiny new product that solves the immediate headache for our customer
  • We’ve then spent some time on improvements to our existing service(s) to ensure that they’ll be able to scale over the next 6/12/18 months as well as tackling some low-level improvements and/or bugs
  • We’ve revisited the shiny product, introduced more features to delight our customers, polished it up a bit and done a proper version 1 release
  • In the meantime, a government body has found the company to be in breach of a certain market regulation and asked us to make a number of changes to our product. We hadn’t planned for this, but we don’t need to worry (in terms of our roadmap).  Our shorter batch model means that we’ve got that flexibility baked in to be able to adapt to unforeseen requests 

Too Good to be True?

This all seems a bit too idealistic. So we simply switch to smaller batches and everything becomes rosy?

Not quite.  There are a few factors that we need to take into account and be mindful of for this approach to work.  I briefly mentioned about the need to balance speed of (valuable) delivery alongside technical impediments.  We also need to bear in mind that we’re keeping a flexible roadmap because of the amount of existing services that we own and that ownership brings with it a support burden.  Whilst we work on our initiatives, we will be dealing with customer requests and outages. This might end up pushing our time to ‘Required Customer Impact’ further into the future. This is a consequence of a large service footprint.  However, there is scope to turn this something a bit more positive.

How about we analyse the causes of the issues we’re seeing, identify patterns, then scope out a short initiative that we can drop into our roadmap that could potentially deal with 50% of support tickets?

Another factor that you’ll need to be aware of is the quick turnaround in delivery times.  If you’re a Product Owner, you’ll really to focus on dual-track scrum to ensure that the next initiative is scoped and ready to go as the current initiative ends.  Understand the problem space, build an inventory of user stories, identify the customer pain points and communicate these frequently to your development team in advance.  Give them plenty of time to ask questions so that you have their buy-in when it’s time to move into the solution space.

Finally, it’s a fact of life that more initiatives will probably equal more up-front documentation. There’s no getting away from this but why not use this as a chance to re-evaluate how you document. Are you actually working waterfall in disguise?  Can your documentation be done in a lighter weight format? Documentation is important but try not to let it be an obstacle to delivery.

Summing Up

Despite these considerations, the shorter batch roadmap model has considerable upsides.  

Why wouldn’t you want;

  • Flexibility in your roadmap
  • More frequent and impactful delivery for customers
  • A better motivated development team

There’s no disputing that it’s challenging to break work down to smaller chunks, but the rewards are great.

If your last project was a big one, why not give this approach a try? It’d be great to know how you get on.

Some Quick Thoughts on Delivering (Customer) Value Constantly

I once had a senior manager who pressed on me, that in his eyes, our engineering team should be delivering customer value with every single sprint.  It felt like both an exciting and daunting ask to make this happen given that we are a platform squad.

We rose to the challenge, changed how we worked and have been operating in this mode for quite some time, and I felt like sharing my thoughts on this ask.

So, is it possible to deliver customer value sprint after sprint?

In short, not really.

We could be optimistic and change that to it depends.   It depends on how willing you are to change the definition of who your customer is because if your only customer is who you’re building for, then I don’t believe this ask is possible.  If you’re willing to be flexible and acknowledge that sometimes you’re your own customer, then it is possible but all you’ve done here is move the goalposts.

Delivering customer impact sprint-on-sprint is the dream but unfortunately sometimes we need to wake up and live the real world.

Let’s be honest and acknowledge that most pieces of work have dependency chains; especially when you first enter the solution space of a project.  Whilst we work through these dependencies, this work will probably not be visible to our end customer.  For instance, have we provided value for them whilst we spun up a new cluster that our solution will sit on?  No, we haven’t, but this work is still essential to the overall project.

I’m a firm believer in ‘thin slicing’ and small batching as much as possible in order to deliver value quickly and continuously to our customers but it has to be caveated. 

My go-to story for communicating this to stakeholders is to ask them to think about building a house with this hypothetical schedule.

  • Sprint 1 (1 week):  Foundations are dug and laid
  • Sprint 2 (1 week):  All the outer walls are erected and the windows are installed
  • Sprint 3 (1 week):  The roof goes on. The customer moves in with a camping mattress and stove, a sleeping bag and a big jerry can of water

Using this example, the very thinnest slice requires that the house be water tight before the customer can move in, even if their existence is pretty primitive with no running water. It’s still taken three sprints to get to this stage though!

Think about delivering customer value frequently.  Although we should be relentlessly focussing on customer impact, we shouldn’t feel under pressure to do it in every single sprint.  And if you ever get pressed on it, feel free to tell your stakeholder the story about building a house…

Weekly Sprint Goals & Planning Canvas

As I sit down to write this, I figure that I’ve now been working in an Agile environment for almost four years and up until earlier this year, three of those were following the Scrum framework and had been time boxed into two week sprints.

That all changed earlier this year when the Data Tribe in Skyscanner — where I’m a Product Owner — decided that all squads within the tribe would work to weekly goals, thereby necessitating week long sprints. This work would then be demonstrated to others — mostly Data Tribe members but anyone within the business could join — on a Friday Show & Tell session. (For more information on the Tribes/Squads model, aka “The Spotify Model”, click here)

Almost a year down the line, I feel that we’ve definitely delivered a ton of high impact work and our customers are delighted with the output of the tribe overall. Largely this change has worked for the better but it did pose some challenges for me as a Product Owner that I needed to figure out.

One of the biggest challenges that I encountered was that Scrum ceremonies were going to remain yet we’d be doing them on a weekly basis rather than a fortnightly basis. In essence, we’d essentially be doubling the number of backlog grooming and planning ceremonies we’d normally do over a fortnight. The answer, unfortunately, wasn’t as simple as halving the time of planning. Sprints still needed to have the same planning diligence but I had to be mindful not to infringe on the development team’s time any more than was necessary.

Historically I’ve been used to bringing in Jira tickets from our backlog, sizing them with the squad and then reviewing them before starting a new sprint. Now though, I needed to find a way to make sprint planning more focused, more concise and eliminate as much waste as possible. At around that time, I was reading a few books and blogs that contained the use of a ‘canvas’ and I thought that might be a fun idea to try and explore.

After a couple nights playing around with some ideas, followed by a few iterations based on planning feedback, here’s what I came up with;


Let’s go through each one of the boxes and talk about its purpose and how it relates to planning — we’ll leave the What’s the Goal box until the end…

Impact

Why are we working this? What will this allow our customers to do that they couldn’t do before? How much time will this save our colleagues in future? Etc. etc.…

This statement is important as it provides the ‘why’. Providing the context for a piece of work is hugely beneficial when aligning the development team with the customer requirements. Knowing the purpose helps foster a sense of ownership as well as reducing the opportunity for confusion once the sprint begins.

Tasks

What do we need to do to complete our goal and deliver impact?

Discuss this with your team and jot down a list of the tasks that need to be done. If you use Jira, this list will form the basis of your tickets for the sprint.

Definition of Done

How do we know when each task is complete? Is there a metric we can tie-in with to show percentage increase/decrease etc.?

Having the squad know what needs to be in place before a task can be marked as complete brings clarity to the end state of each task. Doing this also helps avoid gaps in expectation between the actual customer needs and development team perception.

If using Jira, remember and include these in your tickets.

Risks

Think about the week ahead and what might put your sprint goal in jeopardy. Conduct a mini pre-mortem, imagining the sprint goal not being met and thinking about the potential main causes.

Was this because we were trying something exploratory and weren’t sure of the outcome? Maybe we had an upstream dependency that fell through?

Just taking a few minutes to think about these risks is a really worthwhile exercise for bringing some potentially harsh realism into the process of planning.

Constraints

These are similar to risks but act more as speed bumps towards the sprint goal rather than stop signs.

Some examples of constraints are planned holidays within the squad. It’s not inconceivable that constraints can become a risk which ultimately may lead to a reduction or change in sprint goal.

Measures

What should we be measuring to track progress on our goal? Can we leverage an existing dashboard or should we build a new one to show the impact our work is having?

Suppose our goal was around reduction in latency of x milliseconds by changing y — we might have a dashboard already setup to measure latency. We can use this existing dashboard to validate our progress. Alternatively, we may need to create a new dashboard that better fits our needs — remember and factor this into your tasks for the week if this is the case.

Experiments

This ties in with the Risks section. If we know a task is risky, what can we do to fail fast? If we’re going to build, what should we measure in order for us to learn for the future?

Failing fast on risky tasks works for a variety of reasons in an outcome-driven sprint. Let’s suppose in a worst case scenario the experiment is not successful. Failing fast and early in the sprint gives us a few different options on how to proceed thereafter;

  • We can choose to pivot the sprint and work on something different knowing that we’re blocked on a specific task.
  • We can persevere with the blocker knowing that although we might not make our sprint goal, we’ll be in a much more advantageous position in future.

Show & Tell

Trying to find a volunteer to present at Show & Tell on the day of the session is never an easy thing. A squad will typically be made up of some people who are slightly more comfortable presenting their work and some who are less comfortable.

Spending a few minutes are during planning to discuss both what the intention is to present if the goal is met (such as a dashboard or live demo) as well as a potential volunteer, can make the matter of finding a topic to present less scary and help the volunteer prepare throughout the week.

Note that as we all know; unforeseen circumstances can and will happen during a sprint which might kill the Show & Tell intention. Don’t spend too long on this box and be prepared to change what might get presented. I still find this is a worthwhile exercise to get everyone engaged in the sprint and its outcomes if nothing else.

How did we do?

This is a retrospective box that can be filled in by the PO after the sprint or as a group at the start of the next sprint planning.

Here we acknowledge if we met our goal or not. If not, why not? Did we run over by a day or did a failed experiment cause us to change the entire goal for the week?

Having this documented allows you to track over time the progress towards accomplishing the sprint goals.

Learnings

This is another retrospective box.

Fill this in with any learnings from the sprint that’s just ended. Say for example we’ve not met the sprint goal a few weeks in a row, maybe we’ve simply been overestimating our output capability. Perhaps try reigning the scope in a bit in future?

Acknowledge positive learnings as well. For example, two squad members pairing to share knowledge which in time leads gives greater flexibility within the squad.

The Goal

And finally…

Once everything above has been discussed and we’ve weighed up the sprint impact and tasks versus risks versus staff holidays etc. and we’re comfortable with what can be achieved, it’s time to summarise this into a goal statement. This becomes the opening salvo at Show & Tell; “This week our goal was…”

The goal statement really works best when you keep this down to one sentence and keep it S.M.A.R.T;

Specific

Measurable

Achievable

Relevant

Time-boxed (sprints ensure this by their very nature)

A catchy one-line goal statement is great for communicating the intent of the sprint with both management and customers and provides a ‘north star’ for the squad members to refer back to at stand-ups etc.

I guess that now weekly sprints have been in place a while, I’m in a position where I can give honest feedback on my canvas experiment.

I found filling out the canvas incredibly useful for a few months. The questions it posed were invaluable to both myself and my squad, and it really helped drive a more concise and meaningful discussion during sprint planning.

Overall I’m extremely happy with my experiment. It was definitely worthwhile even if I don’t fill in the canvas anymore these days. I’ve found that the questions are now ingrained in the planning process and instead of using the canvas, I’m filling these answers to these questions as part of my Jira Epic ticket.

In conclusion, even though the move to weekly sprints was not without teething difficulties, I feel that moving to the canvas, even for just a short-medium term helped enable more concise sprint planning and hopefully others reading this might give this a try and reap the same benefits.

Backlog Prioritisation Lessons from #deleteUber

Anyone following any sort of tech news recently would have seen that Uber have been making headlines rather a lot and definitely not for the right reasons! While I’m not going to dwell on their issues — the internet is doing a decent job of that — I wanted to call out the #deleteUber campaign that’s happening as a result and an interesting lesson I take from it as a Product Owner.

Cutting a long story short a proportion of Uber customers fell out of love with the company due to the story and started a #deleteUber campaign encouraging users to delete their account. What fascinates me is the volume of incoming account deletion requests meant that the company were overwhelmed and couldn’t keep up — it turns out that after all this time and with more than 40M riders a month, the account deletion was done manually via their support centres!

While this might seem surprising given the challenge clearly isn’t engineering, when we scratch the surface, use our imagination and allow ourselves some assumptions, we can begin to build a picture of what’s going on (maybe).

Uber is entirely an app based solution. When users fall out of love with an app they’ll simply delete it from their device. This invisible dividing line between device and account keeps the potential for account deletion relatively low; out of sight (on the home screen), out of mind. Yet the account lives on.

With this in mind, I’m pretty sure somewhere in the backlog column of an Uber Jira board, there is a card for automated account deletion.

Now imagine being the Product Owner of said card. The sprint goals will be aggressive and demanding. Ask yourself; “What’s more impactful? Will we contribute to the hyper-growth of the company, or will we automate a task that’s already being dealt with — by someone else — with a few bullet points in a playbook?”

The lesson to me here is that it’s OK for not every card to be done every time. Think about the outcome of the card rather than the output.

  • ‘Is there a use case in the first place?’
  • ‘Will this card get us closer to our weekly sprint goal?’
  • ‘Can we get by in the meantime or is there an even thinner slice we can tackle? (written instructions for example)’

These are the questions I’m asking myself each week as I begin thinking about next week’s sprint goal and how we prioritise to ensure that we as a squad achieve it.

In the end it looks like Uber got this one right; when the volume of requests became a genuine scale problem, the company quickly created a new system that automatically responded to each request with a link to delete each user’s account — the Jira card finally made it up the PO’s priority list!