DOs and DONT’s of remote meetings

It’s sooooo much easier to have a meeting with people being physically present in the room than when some of the participants are joining remotely.

It’s not too bad when every single person joins remotely, let’s say via individual hangouts or Skype, but when the situation is mixed, i.e. there is a group in the room and some other people join remotely, often from a different country and/or time zone, that might lead to a big drop in meeting’s quality.

Experiencing the situation from both ends, I came to the conclusion, that it doesn’t have to be this way and it’s not the distance or technology that is the problem. It’s the culture of people being in the room that has to change. Spotting some bad habits is the first step to eliminating them.

The usual setup of our meetings is the most complex one:

  • A bigger group in the same room – a mix of native and not native English speakers
  • A couple of smaller groups in different countries and different time zones (fortunately just 1 hour difference), usually just non-native English speakers
  • Single participants joining via hangouts from various locations, various nationalities

Here is a list of some dos and dont’s that help us these days:

Do: Prepare up-front

For some reason the technology does not always work the first time – usually, a remote participant can’t hear you or you can’t hear them. The problem might be on either end and it sometimes requires reconnecting or trying out a few settings, which might only take a few minutes, but the more people join the meeting, the more expensive this wasted time is. Let’s say it’s a dozen people waiting for 5 minutes: 12 x 5 = 60 minutes! That’s 1h wasted of the organisation’s time on a setup.

Simply come to the meeting room a few minutes earlier (or ask everyone to come a few minutes later) and test the setup.  

Do: Stay close to the mic – or keep the mic close to you

Ok, this is to do with technology. It doesn’t matter how good the microphone is – its range is always limited. While the person staying close to the mic is heard properly, the further you go away from the mic, the quality drops significantly. Even if you turn your head away – it will impact what remote participants can hear.

We solved this problem by introducing a rule, where a token is passed between people in the room, and only 1 person can speak at any given time (the person with the token), the token being a Jabra speakerphone. 


It seemed awkward at first, we felt like the dynamic of the conversation slowed down, but that is actually a good thing. People ‘on the other side’ – usually not native English speakers appreciated the second of silence between the speakers in the room. This is also enforcing a cultural shift – let the speaker speak with no disruptions from others.

Don’t: Multiple conversations at the same timemultiple conversations

Passing the mic to the speaker definitely helps here, but it can’t really stop people based in the room from having more than one conversation at the same time. Make everyone aware, that this is not good – remote participants will hear a mash of dialogues and will not be able to understand anything.

Do: Moderate the speed and volume of your voice

people and volume

The variety of the speech speed and volume of participants in the room is usually wide. Some people are naturally very quiet while others are quite vocal. Same goes with the speed of talking. This is proving difficult not only for remote participants but also for non-native speakers in the room. It takes a while to get used to someone’s accent or set of words they are using. Remember that the quality of sound from a computer will always be worse than in the room. Try to slow down and speak louder, maybe even repeat the key parts, like you would to an elderly person.

Do: Let remote people see the speaker

invisible speaker

A conversation is not just voice, the body language is telling a lot. It’s not critical, but it helps when you can see the speaker pointing at something. If the speaker is not visible for remote participants, they first need to guess who is speaking, which takes a small portion of their attention.

Do: Watch your body language

person thinking

We don’t realise how much of our speech is done via hands. Many times we draw pictures in the air illustrating an idea or point at some print outs. Can the remote guys see you doing this? Will they see the small print?

How about your hands covering your mouth when you do some thinking and talking at the same time? Even when you support your head on your hands, this might be distorting the sound waves which only get worse on the way through the internet.

Do: Repeat the question from the audience

When one person is presenting to a larger group, the mic is usually fixed to the speaker and the audience is there just to listen. On many occasions though, someone in the room throws an unexpected question. The speaker is usually jumping to an answer, forgetting that the remote people didn’t hear the question. It’s a good practice to repeat or rephrase the question before answering.

no question answer

Don’t: Jargon, idioms, politics references

This is related not only to remote meetings but to any meetings with people from different countries, especially if some of them are not native English speakers.

The idioms or references might not be understood, leading the audience to a) confusion b) asking questions and taking time from everyone in the room c) habit of ignoring parts of the conversation. Listen to what you say – would you say the same things in a foreign language?

Don’t: Read a written text

reading out loud

We read faster than we speak. I noticed that people who read text out loud, try to catch up with their eyes which make them sound really blurry sometimes. They don’t notice that because their eyes can see the whole text, but for people who listen – it’s often not clear. If you really have to read a paragraph of text to someone – slow down and pause often. Remote people will appreciate it.

Do: stay present 

Whichever end of the meeting you are – remote or in the room – stay present. Do you really need to look at your emails on your phone or laptop? Maybe you should be somewhere else instead?

To finish lightly – here is a fun video of how remote meetings look in real life.

Hire for attitude

Never being part of HR team, I’ve been involved in interviewing people for many years. I wish I collected some data over time, but well, I didn’t. The fact is – I’ve learned a hell of a lot about people (and myself) in this process.

What I was looking for in a candidate years ago is different to what I look for these days. Yes, I still look for skills and experience, they are important, but it’s not the full recipe for a great colleague. The world is changing so rapidly, that something you excel in technically today might be worthless in 5 years time.

Most of all, I am looking for the right attitude. Someone who happily checks their ego at the door (work is not a competition!) and puts their whole hearts into the job. In other words – if you are at work – truly be there, not just sit there. It’s not even coming to the office that matters here – wherever you are – are you mentally at work or would you rather be somewhere else?

Part of the right attitude is proactivity. A lot of people simply wait for permission (many never even ask, just assuming the answer would be no). If you are passionate about what you do, mature enough to understand the consequences and truly believe it’s the best thing to do – just do it! Apparently, it’s proven that in the long term we regret more the things we didn’t do rather than the ones we did! So – if you believe it is the right thing to do – ask for forgiveness, not permission (some of my colleagues hear it a lot from me!).

Now, something essential that is a result of the right attitude and proactivity (or maybe it’s the other way around?) – learning. How do you educate yourself? How much time and/or money you invest in your development? How hungry (for knowledge) are you? And what did you learn from your own career so far?

Part of the learning process is sharing what you learned with others. Some people say there is no value in it (!) and it makes me cringe. It’s a short-sighted view in my opinion. Education is not an instant coffee, the benefits will not always show up the next day. We learn by doing and teaching is doing.

These are of course my values, based on my own experience with candidates. I am not an HR person and I probably missed some other important aspects. But well, I am still learning! And sharing: here is an excellent video about behavioural interviews by Jackson Gabbard. It’s one hour long, but worth the time.

Now – teach me something!



Can trust be calculated?

Relationships with people play a big part in the success of a product owner. They usually get better in time, but not always. Investigating some recent issues, I bumped into a trust equation. Yes, a formula that helps calculate trust.

Here it is:

Trust = (C + R + I) / S

C stands for Credibility. In other words ‘do you know what you are doing?’. If your colleagues or stakeholders don’t think you are an expert in your field, they might trust you less than you would like. So the question here is – how can you demonstrate your skills? Is there something you could teach your colleagues? How transparent are you with what you do, how and why? I.e. do your stakeholders know about the case studies that influenced your decision or do they think it was a gut feeling?

R stands for Reliability. Can your colleagues and stakeholders count on you? The answer usually comes with time and it’s based on past experiences. The question to ask is – have you always delivered as expected? Agile and its small batches of deliverables might be a great help here – deliver often and you will appear more reliable.

I stands for Intimacy (as strange as it sounds in the business context!) The question is – do they like you? It’s been proven that familiarity increase liking, so if this is your struggle – think of what do you have in common with your colleagues. Some common barriers here are – remote locations and the cultural differences. Sometimes, an email written by a non-native English speaker might sound harsh to English people, even though it was not the intention. My advice here would be to increase face to face time, even if it can only be done via a video call.

S stands for Self Orientation. In other words – do you really care about the stakeholder and the business or do you have a hidden agenda and only care about your own progression? As this is the denominator in the equation, it might quickly suppress all the other factors, so it’s important to simply be genuine. Check your ego at the door and stay as transparent as you can. If people don’t know reasons for your behaviour, they will assume some (not always fair!) and in time they will treat it as a fact.

All of the factors influence each other and should not be looked at in isolation. A great starting point would be to identify the weakest factor and start from there. We recently used a scale 1-5 for each of the factors and did the calculation. The result was not great (I call it an opportunity) so we agreed some actions to take and in 3 months time we are going to calculate it again.

Here are the book and a short summary video.

Are there any more ingredients of trust? Probably. I am going to explore the equation as it is first and see what happens. I’ll let you know if I discover a missing part.

Can every meeting be a Lean Coffee like?

Every time I am in a meeting with a missing agenda or when an agenda item is dragging forever, I think of the Lean Coffee format.

The recipe for a Lean Coffee meeting is simple:

  • There might or might not be an agenda to start with.
  • People get together and individually write the topics they want to talk about (post-it notes work well here).
  • There is a dot-voting to decide what to discuss next (just the very first topic).
  • The timer (usually 10 mins) starts.
  • People discuss the selected topic.
  • When the timer goes off, there is thumbs-up/down voting to decide if the topic is finished or requires a further discussion. NB: thumbs down mean – ‘no need to discuss anymore’, as opposed to ‘the speaker was crap’ or ‘I completely disagree’.
  • If the majority of thumbs went up – the timer starts again and the discussion continues. If decided otherwise – the next topic is chosen and the cycle begins again.

It’s such a simple method to stay focussed in a meeting, without being rude to anyone who likes talking too much…

Can this be done remotely? Of course – just use a shared doc instead.

Probably not every meeting could be a Lean Coffee one, but a lot of them have the potential!

What if there was no backlog?

The biggest backlog I came across contained around (!)3500 items… I can’t imagine a product owner or a team who would really understand what’s in it.

It kept me thinking – why did it happen in the first place? One of the conclusions was, that product owners, not wanting to say ‘No’ to their stakeholders, say ‘Not now’ and add their requests to the backlog. Realistically, most items in the backlog never get done, but the loss aversion bias prevents us from getting rid of these requests. So the backlog keeps growing.

Short term result is good – the product owner does their job and documents the request for later, the stakeholder is informed that it might take some time to deliver the request, but it can be done, the team carries on with what they were working on. Everyone happy.

Well… There is a dark side of this approach.

Usually, the backlog (a.k.a demand) grows faster than the capacity of the team. This means:

  • the number of items in the backlog grows, so simple tools might not be good enough to provide a backlog for the team anymore
  • backlog grooming sessions are now longer and/or more frequent
  • stakeholders wait longer for their requests to be delivered (partially because the queue is longer, and partially because the team is busy grooming the queue for longer or more often)
  • some new requests jump the queue because they are small, which makes the waiting time for older backlog items even longer
  • some work becomes super urgent (deadlines!), which means the developers need to drop everything they were working on and switch the context to the urgent thing
  • rushing to complete the code leads to low quality and technical debt
  • stakeholders subconsciously start counting time from the moment they hear ‘it’s in the backlog’, so they are going to get frustrated at a later stage when they discover that their request has not been picked up yet

Less is more

Have you noticed, that most restaurants don’t accept more customers than they can serve at any given time? In some cases, they advise on a waiting time. If it’s reasonable, some people wait, but a lot of them will simply go somewhere else and still have a good time.

Your stakeholders might not have an option to go somewhere else though. Managing their expectations is even more important in this case. It’s more difficult compared to ‘Not now’ but always works better in the long term. My advice would be to try working with the stakeholders at this point and decide together on what’s the most important thing to do. Agree on a limit for the number of backlog items and if there is something which is more important than other items in the queue – remove a backlog item that is least important at that time. A nice trick here is to exchange a number of tokens between the team and the stakeholders. A completed request = a token returns to the stakeholder and there is a space for a new request.

A thought experiment

What if there was no backlog at all? Imagine this:

  • every time when the team completes work, there is a negotiation with the stakeholder on what’s the (one) most important thing to do next
  • there are no backlog grooming sessions
  • there are no extra tools needed for managing the backlog
  • there is no jumping the queue problem, as there is no queue, the team already works on the (one) most important thing
  • lead time (time from the request till delivery) and cycle time (actually delivering the request) are the same
  • there is a slack in the system (and there is nothing wrong with people not being 100% utilised!)


But is it possible to not have a backlog in real life?

Probably not, but trying to reach a great goal which is not possible to reach, still leads to improvement.

So, dump your old backlog and start afresh. Keep it short. Delete stuff. Important requests will always bubble up. Not important ones will go away.

Less is more.

Draw everything

On many occasions, words are not enough to explain a complex concept. And even if they seem enough, you might discover that if you sketch your thoughts in a meeting, you and your colleagues are not on the same page at all.

No, you don’t need to be an artist. If you can draw a rectangle, a circle and an arrow – you are in! The good news is, there is no right or wrong way of doing it!

Why bother?

Some say a picture is worth a thousand words, but I think there are some other good reasons:

  • this approach lets you step back and look at the problem conceptually before diving into details
  • if you are already talking details, you can then find connections that were not so obvious to start with
  • it helps everyone align and spot major thinking flaws sooner rather than later
  • you remember the details of the meeting for longer
  • drawing during the meeting makes you pay attention all the time (no daydreaming 🙂 )
  • it’s fun!

Sometimes, when I am acting as a facilitator, I draw the key thoughts on a whiteboard before the meeting, so it helps me remember what I want to say and it helps other to remember that later. Win-win.

This week, I was pitching a concept of a lean organisation. A good representation of what I wanted to talk about was… a pipe. No artistic drawings, just a couple of circles and arrows. This helped me explain why aligning a number of development teams, is important for a large software platform. It worked perfectly.


Give it go! Information is beautiful.


Giving feedback

Giving and receiving feedback is a difficult task but it is also extremely important for any team. For a while I didn’t realise that giving feedback that wasn’t good enough, might actually be pointless or even lead to frustration.

There is an excellent team exercise that illustrates the case.

  1. Sit a team member on a chair and give them a set of tennis balls (the more the better).
  2. Place a bucket behind the person (best at an angle), so they can’t see it.
  3. Ask the person to throw the balls behind them one by one (without looking), so the balls end up in the bucket.

feedback chair

Now, consider following scenarios:

  • Scenario 1: The person gets no feedback at all, but is still expected to place the balls in the bucket.
  • Scenario 2: Very negative feedback (i.e. ‘that was useless!’) is given when the balls miss the bucket.
  • Scenario 3: Very positive feedback (i.e. ‘well done, keep trying!’) is given even when the balls miss the bucket.
  • Scenario 4: Constructive feedback (i.e. ‘a little bit more to the left’) is given at any time.

Now ask the person how did it feel.

In Scenario 1, it’s a pure lottery. The person does not have any chance to improve.

Scenario 2 is actually very frustrating. The person is trying hard but the effort is only criticised. If you try that for long enough, the person might get annoyed and refuse participating further.

Scenario 3 is not much better. It is definitely motivating but not helping. Giving only positive feedback is not enough to improve!

Scenario 4 illustrates the best way of giving feedback – informative and honest. Feedback that will help adjust next steps, so eventually the goal can be reached.

From now on, I am going to ask myself before giving feedback –  is it going to help the other person or is it just words?



Pre-mortem retrospective

This type of retrospective is great for teams working on a new product with a given deadline. The idea is simple – just imagine that the launch date has come and the product… failed miserably. Yes, imagine you failed.

It’s important to imagine it in great detail and capture all possible problems, even if they seem unlikely to happen, they are outside your control or just seem silly. Ask people to get super creative, the sky is the limit here.


I was surprised how quickly my team generated so many post-it notes with potential problems written on them, that they didn’t fit the designated box and we had to double its size.


For a moment we completely lost the confidence in the product… We knew the deadline was tight, but it still seemed doable (before). Looking at the board covered completely with potential problems was an eye opening experience – yes, there is a chance of failure…

Luckily – there is still some time left and there are things that can be done to prevent or mitigate the issues.

Get proactive!

We started from grouping the problems into themes.




Having stakeholders participating in the exercise turned out to be very beneficial, as the dev team focussed mostly on technical issues and less on the business side of things. The success of the product is however a complex thing and stable software is just one of its factors.

After grouping all the problems into themes we discussed which of them are real show-stoppers and which are likely to happen. We also excluded the ones we don’t have any control over and focussed on remaining issues.

Problem filters

It turns out that there are quite a lot of things we could do to mitigate the risk of failure. We have generated a list of actions and scheduled some of them to happen really soon, i.e. meeting an expert in the area of where the product is going to be used. Other actions will rather be ongoing – i.e. ensuring a fast feedback loop by engaging in all sorts of activities with potential business users.

Key benefits

  • You’ll uncover potential problems, which might have been a taboo till now.
  • Proactive approach mitigates the risk of failure.
  • Stakeholders manage their expectation better by understanding the technical challenges better.
  • Dev team understands the business perspective better and how critical their work is.

Attitude to failure

I believe in being proactive, but I’d like to stress here, that avoiding failure is not the point. Paraphrasing Matthew Syed from his excellent book titled ‘Black box thinking‘ – we need to change the attitude to failure. Stigmatising failure will lead to fear and might blind us to bigger problems. Failure is (!) good. So, fail fast and learn fast!

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.