Time management

Product Owner is a complex role. It includes aspects of other jobs – there is a bit of being a business analyst, a project manager and UI/UX designer. Product Owners are often involved in very technical conversations and very high level business meetings. That makes the job very interesting. On the other hand – Product Owners can struggle with managing their time efficiently, as there are too many resources competing for their attention.

One day I decided to analyse how can I better protect my time.

Start from data

I started from analysing the past 10 weeks of my work. Where did the time go every day? This was a shocking discovery – every week I was spending in average 20 hours in meetings. That’s half of the time at work! This is how my calendar looked like almost every week:

blurred calendar
My calendar (intentionally blurred)

It wasn’t just the number of meetings, it’s their timing that made using the remaining ‘free’ time difficult. Having just half an hour break in between meetings is not enough to get work done – by the time I get ‘into the zone’, I need to go to another meeting.

Meetings should be like salt

Repeating after Jason Fried, the author of the book titled Remote:

“Meetings should be like salt – a spice sprinkled carefully to enhance a dish, not poured recklessly over every forkful.”

I absolutely love this quote and think about it every time when there are 10 or more people in a meeting.

Where else was my time going?

Meetings were definitely the biggest factor causing a problem, number of emails came second, followed by something I call ‘other people’s agenda’ and ‘just a quick question’.

There is nothing wrong with all the above (communication is very important after all), but if they happen randomly during the day, they might devastate productivity. And this is what was happening in my case.

Screen Shot 2016-03-26 at 16.35.35
Excellent illustration from ‘Remote’ by 37signals.

Improvement goals

Before brainstorming ideas for improvement, I set myself a few goals:

  • Reduce time spent in meetings by 25%.
  • Reduce context switching to 4 things a day.
  • Increase focus time to 12 hours a week.


I came up with a lot of potential solutions, but introducing all of them at once would be difficult. Instead, I picked a few and decided to trial them for 4 weeks.

Solution #1: Meetings limit

The new rule says: no more than 3 hours a day, alternatively – no more than 15 hours a week spent in meetings. Also, if anyone asks me when I am available to meet – the answer is ‘Next week’. Before, I used to look for the very next available spot in my calendar.

It’s surprising how many problems can solve themselves within 7 days!

Solution #2: New desk setup

Having collocated dev teams, sat just around my desk makes the communication between us super easy. It leads however to a lot of ‘quick questions’ and other interruptions to which I can’t say ‘no’, as by definition, Product Owner should be always available to the team.

So what can I do to get less interruptions? I have found myself a new desk. This is my ‘backup setup’ (a proper one, with secondary monitor etc.). It is in a different building, where I am surrounded by people from a completely different department, so they have nothing to discuss with me. Just to be very clear: I am there to focus, I am wearing big headphones, which minimise the background noise. I’ve also joined Spotify which offers great selection of ‘Focus’ music (‘Productive Morning’ is one of my favourites).

Solution #3: Focus blocks

This requires a little bit of planning in advance. I am scheduling 4 blocks of time, 3 hours each, in my calendar for the following weeks. The calendar shows that time as busy, so it stops (some) people from booking their meeting as soon as they see a free spot in my calendar. I spend this time in my secondary location, trying to dedicate this time to just one subject.

Solution #4: Email batches

Emails are the main reason of context switching, even if they don’t require any reaction. I realised that having Gmail constantly open in one of the Chrome tabs, I kept switching between what I was working on to emails all the time.

Not any more. The Gmail tab is not open at all. Instead, I have Google Mail Checker Chrome extension installed. A new icon, just beside the search bar is informing me about the number of unread emails. I am ignoring it until it shows at least 10 new emails, only then I am allowing myself to open Gmail.

There are a lot of other little things that can help manage a large number of incoming emails. The following list is for Gmail, but other clients might have similar features:

  • Labels – they are visible on the list of emails and flag emails meeting certain criteria, for example emails sent directly to you or to a specific group of people.
  • Filters – useful for unimportant notifications that can go straight to Archives, skipping the Inbox.
  • Archiving emails – Inbox is not a bin, so keep it lean and archive all emails that don’t require attention any more. This way the Inbox becomes a to-do list. On an ideal day this list is cleared to 0 by the end of the day.
  • Muting email threads – if an email conversation does not require you any more – simply mute it. Any more emails in the thread will be archived skipping the Inbox.
  • No invite notification – if you are the one setting up a meeting, you will be getting notifications every time when one of the attendees accepted or declined the meeting. Just turn it off, if someone can’t come to your meeting they will most likely contact you directly.

Solution #5: Calendar setup

I want my weekly calendar to be so obvious, that a 1 second glance at it could tell me my schedule, without a need to drill down into meeting details. There are a few little things that can make a big difference:

  • Colour coding – every main stream of work (i.e. every team I work with) has a fixed colour, so meetings dedicated to each of them are coloured ‘their’ way. This helps me to instantly know where my focus is going to be and I can spot difficult days, when my attention will be spread across many different subjects.
  • Hide declined meetings – if I already decided not to go to a meeting and therefore declined the invitation – it should not make an extra noise in my calendar.
  • Fix working hours – you can set your working hours, so anyone who tries to invite you to a meeting outside this time will get a warning. I’ve set mine to core hours only (10am-4pm), even though I work more than that.
  • Hide weekends, morning and evenings – why waste space on your screen for times which will never show anything?
  • Merge meetings – when viewing other people’s calendars, same meeting is shown multiple times. This plugin merges them into one, which improves visibility.

Solution #6: Trello board

Among of other good tools, I am using Trello. It’s great for managing to-do lists in a simple, yet powerful way. The improvements of my default Trello setup I made:

  • Categories of work – my ‘to-do’ list is now represented by multiple lists – one per main stream of work (so 5 lists including ‘Other’). Every card is colour coded (using Trello labels) according to the stream colour (following my calendar and emails). There is also one ‘In progress’ and one ‘Done’ list.
  • List limits – keep the lists short, like you would on the kanban board. There is a good Trello plugin that will help by colouring the list in bright red if you are over the limit and in orange if you just reached the limit.
  • Count cards on the list – this Trello plugin will count cards on the list, so you know how long the list currently is. Helpful for longer lists.
  • Lists layout – keeping lists short results with a lot of unused space on the screen, as Trello lists are only displayed in columns – one list per column. This Trello plugin helps fitting more lists in the same space.
  • Ageing cards – it’s a Trello setting. If a card was not updated for a while it will fade, a little bit more every day. That is a good indicator of tasks that might not be that important, like it seemed originally.
  • Stickers – little images that you can stick to a cards. Useful to flag issues.
  • Grooming session – like any other backlog, Trello boards need regular grooming. However daunting it sounds, it’s worth doing.

 Solution #7: Lab day

This might sound counterintuitive, because I am trying to free up some time, but it’s my favourite. It was inspired by my teams, who spend a day and half every 2 weeks on ‘lab days’. It’s a time when they can work on anything they want in order to improve craftsmanship. They research, try out new technologies and play with the code, which is not related to their daily work. It proved very successful so far – on many occasions people used the new skills to improve existing projects. Why there is no such thing for Product Owners?

I’ve decided to try it too. Once every two weeks (on Fridays), I turn out-of-office assistant on and work from home. I research, write articles, look for conferences or trainings and play with ideas. I’ve only done a handful so far, but it proves very successful already.

How do I know it really works?

It definitely feels better having these solutions in place, but how do I know I am successful?

I’ve set up a short survey for myself, which I am filling out every day before leaving the office. Initially I was only going to do it for 4 weeks, as a trial for the solutions described above. I found it so useful however, that I continue filling out the (modified) form.

Some of the questions on the form:

  • Time spent in meetings?
  • Number of focus blocks completed?
  • Number of [stream name] tasks completed?
  • Is overtime needed tonight?
  • Any challenges?
  • Rate productivity (1-5)
  • Rate happiness (1-5)

I am analysing the data every 2 weeks and decide if any further actions need to be taken.

Key benefits

  • Reducing context switching increases productivity and decreases frustration.
  • Small improvements all together might make a big difference in overall efficiency.
  • Regular retrospectives on daily work lead to continuous improvement.
  • Improving craftsmanship ensures best quality of the job.

Warning note

It requires quite a lot of self discipline to stick to all the rules described above.

So, where is your time going into every day?

Retrospective on enjoyment and business value

Software development is not all about the business value, you need to enjoy what you are doing as well. And this is a good idea for a retrospective meeting for an agile team. My team decided to test if there is any correlation between enjoying working on a story and its business value.

The source of data were about 20 completed stories from the backlog put on post-it notes. The very latest completed story landed in the middle of a graph, where X axis represented Enjoyment (did we enjoy the work, was it fun, technically challenging, insightful?) and Y axis represented Business Value (how useful do we feel the story was to the business).

value v enjoyment-01


We were thinking in relative terms, so the bottom left part of the graph didn’t mean absolutely no value and absolutely no fun (what Product Owner would allow that anyway?), but the least value and least fun out of all the analysed stories.
Having the first story in the middle of the graph, every other story was judged compare to it – was it more or less valuable/fun?


value v enjoyment-02Having judged the latest completed stories, it was interesting to see where the upcoming stories would be placed. We put them on the graph in orange.

value v enjoyment-03

Best stories

What made some stories landed in the top right corner of the graph? Quoting the team:
  • Larger pieces of work
  • Time to get stuck in
  • Genuinely interesting and novel work
  • Business value is very clear
  • Lots of coding involved
  • Requires creative problem solving
  • No external dependencies on other teams
  • Really positive user feedback
  • Well aligned with the team purpose

Bad stories

A couple of stories landed in the bottom left corner of the chart. Why? Quoting the team again:
  • Repetitive
  • Not sure why we are doing it
  • No feedback or metric that it made any difference
  • Not much coding – think config changes and software upgrades
  • Always blocked on other teams
  • Seemingly simple change but large time investment
  • Delayed business value – no immediate benefit

Is there a correlation?

We discovered that when the business value is clearly communicated and feedback passed on to the team – it definitely influences the enjoyment rate. It was a very important message to me, as the Product Owner.
There are however other factors that have an impact on ‘being in the zone’ while working. There are some great books about it, to mention just a couple:

A good summary of the latter can be found on this youtube video.

Can bad stories be mitigated?

The team believes so. If a bad story can be spotted early enough, we can try removing blockers in advance, automate it, get a better understanding of the purpose, or… maybe not do it at all?
Business value versus enjoyment.jpg

Key benefits

  • You will understand what is really driving the team.
  • You’ll have a chance to improve upcoming stories.
  • It’s always good to discuss the business value.

Waste snake

This sprint we decided to focus on eliminating waste. At the beginning of the sprint we agreed to a definition of waste: anything that’s not directly related to working on sprint stories. According to this definition – daily stand-ups, sprint planning and retrospective meetings (and any other meetings), refactoring the code, reading manuals, working on support issues or bugs – that’s all waste.

Waste snake

Every day, we were recording wasteful activities on post-it notes, including how much time they took. We were posting them in a central place, building the body of a waste snake.


It was interesting to see how the snake was growing on daily basis. Very quickly there was not enough body in the snake and post-it notes had to cover older notes making the snake fat. At some point we simply moved the tail to get more space.


Before the retrospective meeting, I quickly grouped duplicate notes and summed the total time of the snake. The first task for the team was to estimate how much time they recorded in total. Surprisingly – the estimate was only 30% of the value!


The next task was to group the waste into 5 categories, which didn’t have names yet (except for the obvious one – Meetings!).


Categories the team discovered were as follows:

  • Meetings
  • Support issues
  • Stupid discussions(!)
  • Learning
  • One-timers


It turned out that meetings wasted most of our productive time. Support issues were rather a surprise – we didn’t realise that we were disturbed so many times during the sprint (context switching!). Quite an unexpected category from my perspective was ‘Stupid discussions’.

According to the initial definition, learning did not directly contribute to the sprint, but it’s necessary in the long term perspective. We moved all post-it notes like that to a piggy bank. Here we had a little debate – are meetings a waste or an investment? Do we need stand-ups every day?


That left us with with a ‘real’ waste. Could that be avoided? What could we do to stop it happening?


Unfortunately it’s not possible to avoid all of the waste, but there are tricks to mitigate it.

  1. Stupid discussions can be stopped by a Mango rule. Whenever someone feels like the conversation is too much off topic – just stop it by saying ‘Mango!’ (or whatever other word the team would like).
  2. Meetings could be shorter. A standing retrospective we ‘accidentally’ tried when discussing the waste snake – actually made us go straight to the point and we did finish earlier than planned.
  3. Pomodoro technique is a good way of reducing context switching, which is much more costly than it seems – coming back to the ‘zone’ after a distraction might take even 15 minutes!

We also wondered if switching from Scrum to Kanban would help to better use the time. That is still open for a discussion another day.

Waste snake’s goal

That’s important – the goal of this retrospective was not to control the team by understanding how they manage their time, or by recording every single wasteful activity. The real goal was to raise awareness of waste as the opposite of delivering value. There are many ways of using the time more effectively, but the first step is to recognise the need for it.

Some obstacles

  • Some people might be reluctant to take part in this exercise and openly admit to wasting time.
  • People need a reminder to note things down (I was sending an email every day containing some facts about snakes or a funny picture of a snake. Also, everyone got a print out of a snake).

A little success story

I overheard a conversation when a team member said: ‘Maybe Anna is right and we shouldn’t work on this problem right now – it’s nothing to do with this sprint stories, so it’s a waste’.



Backlog grooming

To be honest, we don’t do backlog grooming sessions too often. By focussing on what’s at the top, we believe that everything else simply doesn’t matter. Yet.

FullSizeRender (5)

This down-to-earth approach can get out of control, especially when anyone from the team can add backlog items that need work ‘at some point’. When not watched, this can lead to a fat and ugly backlog over time, where user stories are waiting forever to get done. Seriously – having a small agile team and 100 items in the backlog – do you really believe that item #100 will ever be done?

Knowing our velocity, it would take about 8 months to complete all the backlog items. That is assuming that no new bugs, important requests, or the need to rework an item doesn’t appear in the meantime.  In theory, any new request would need to wait 8 months. That’s not very agile, is it?

If in doubt – remove

One day we decided to challenge the situation and leaving just 4 top stories in the virtual Lean Backlog box, we moved all the other backlog items into a virtual bin.

Seeing all the backlog items in the bin came as a bit of a shock to the team at first, and the loss aversion bias kicked in: ‘We can’t just delete the whole backlog!’ the team said. ‘Can’t we? Can you even tell what is in the backlog at the moment?’ – I asked.


Sell it or lose it

The first task of the session was to sell each backlog item to the team, or in other words – prove its importance. Questions we were asking were along these lines:

  • What’s the real impact of this item?
  • Who are the stakeholders?
  • What’s the cost of delaying this item?
  • What’s going to happen if the item is not done at all?
  • Can we justify working on this item within next 3 months?
  • Is this really so important if nobody chased that issue for so many weeks/months?

Surprisingly, we realised, that we didn’t even remember adding some of the items to the backlog, let alone being able to explain them in details. In the end, only 40% of the items managed to get out of the bin. That means – 60% of the backlog items deserved to be deleted!



All remaining items had to go through prioritisation process – comparing business value and development effort required.


Essentials only

This approach, leaving us with a healthy backlog with only essential items, was inspired by company called 37signals and their book titled ‘Getting Real‘, which you can get for free. This is what they think:

Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club.” You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. That’s why you start with no. Every new feature request that comes to us – or from us – meets a no. We listen but don’t act. The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.