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?



Cumulative Flow Diagram and WIP limit

One of my teams works with Scrum. We usually take about 5-6 stories into a sprint.

We noticed, that sometimes we had a problem with finishing all the planned stories, even though our estimations did seem to be correct. It might be quite normal for Scrum teams, but we decided to rely on data to tell us what we might be doing wrong.

Tracking tasks

As 5 stories is not that much data to track, we decided to track the flow of all tasks instead, ignoring the actual stories for this experiment. Every day we were noting down how many tasks were residing in each column of our physical story board, which looks more or less like this:

To do Doing To review Reviewing Done

Cumulative Flow Diagram (CFD)

At the end of the sprint we illustrated what was happening every day by using Cumulative Flow Diagram. To our surprise it looked pretty bad! We didn’t even realise that we were going nowhere while days were passing by.

The blue part of the diagram (‘Done’) was supposed to go up diagonally during the sprint, but almost didn’t move. The purple part of the diagram (‘To do’) completely dominated the graph. Not good…

Sprint Z
Cumulative Flow Diagram of a bad sprint

WIP limit

We realised, that we were working on 11 tasks at the same time, while there were only 4 of us. By ‘working’ I mean all tasks that were neither in ‘To do’ or ‘Done’ sections. At this point we concluded that we needed a WIP limit. Starting from next sprint, nobody was allowed to start a new task, if there were 5 tasks already in progress (between ‘To do’ and ‘Done’).

It was a bit annoying at the beginning, but somehow tasks got reviewed much quicker this way, as they were blocking access to new work. Also, any problems that were normally discovered at the end of the sprint were now visible much earlier in the process.


Just a few sprints later we were fully up to speed and tasks were flowing really quickly.

Have a look at the CFD of the following sprint:

  • The ‘Done’ part goes up diagonally, almost with a constant speed – we are continuously delivering!
  • There is a step in the ‘To do’ area because we needed to add more stories in the middle of the sprint, as we were moving faster than expected.
  • The tiny section between the blue and purple areas means that the number of tasks in progress at any time was minimal (WIP limits!)
Sprint H
Cumulative Flow Diagram of a good sprint

Good WIP limit value?

So what is a good limit for work in progress? That depends on the size of the team and on how much you want the team to do pair programming. Initially we set our WIP limit to 5 tasks for 4 team members. Today, having 8 people in the team our WIP limit is 7. That is to ensure we don’t work in little silos.

Key benefits

  • A CFD shows exactly what happened every day, while we (humans) wouldn’t remember the sprint this way.
  • WIP limits mean less work started, more work finished.
  • WIP causes work to be reviewed quicker, which highlights any issues earlier in the process.
  • WIP helps to decrease context switching, which in effect makes us more efficient.


Role reversal

We started our research from shadowing users. All team members spent a whole day working with the people who are using our product – internal users – delivery drivers. It wasn’t training, we were actually helping the drivers deliver shopping to real customers.

We learnt a lot that day – about the users themselves, about the delivery process and how it is really handled by the system we provide, and a bit about the customers. We felt like experts for a while, even though it was very limited qualitative research.

We decided to put it into test however and invited an experienced user to a workshop with us. Our first task was to… reverse our roles (kind of).

So, this is your job:

We asked Mike-the-user to pretend that it’s his first day at this job, even though he’d spent the last 10 years doing it. All he was supposed to know is that the role involves delivering goods to customers.

Next, we asked the dev team to pretend they are his line managers and they need to explain the job to him – step by step. Mike was a curious student, so he was allowed as many detailed questions as possible.

It started well, but very soon we got corrected: nope, it’s not how it works…

We were missing details, got some procedures mixed up and couldn’t answer some of the questions, even about our own system! We also discovered how our system can be misleading if things go wrong.

We are not on the same page

giphy -shaking head

We now know that even by shadowing users, we can still misunderstand things. Especially if things go well during the day – we can’t see the whole range of issues our users face. Also, we are more likely to believe that problems that occurred during our experience are happening more often, when in fact, they might be statistically rare.

So we are not on the same page. And we will never be. But that’s ok – we are very different people and have different skill sets – that’s why we have different jobs. What we should do is to work towards minimising this gap by educating ourselves about the users, and also educating our users about our job when possible.

Key benefits

  • The meeting is more engaging for everyone.
  • We actively think about the process (as opposed to passively listening about their job).
  • Misunderstandings are spotted quickly.
  • We build a relationship with users.

Try it yourself – explain to your users what their job is. You will discover a lot of surprises.




Legacy product roadmap

It’s great when you can create a new product from scratch, it’s a different story when you inherit an old and complex system. Especially when the whole development team is new and they don’t know much about the product yet.

Before deciding what should go on the roadmap, we spent some time getting to know our users (including creating personas), speaking to their managers and other stakeholders and analysing recent support issues. We concluded as follow:

  • There are thousands of new users, who struggle with the system.
  • There are thousands of experienced users, who got used to it and don’t want any changes.
  • Stakeholders have been asking for new features for last few years.
  • Promises were made to the users and not delivered.
  • Legacy code and technical debt are rather scary.
  • There are a lot of support issues.
  • There is a lot to learn about how the system works (and no manual).

How did we tackle this?

We started from inviting our stakeholders to the meetings. Their input is critical for a successful and realistic roadmap.

Roadmapping part 1

Before the meeting we printed out all screenshots from the current system. We were all surprised how many there were (50+ screenshots!). Surely, the home delivery process can’t be that complicated? No wonder new users feel lost.

(Some) Screenshots


Task #1

Everyone got a few post-it notes to write down what are the top 3 problems our users are facing. Some people wrote more than 3, so we asked them to prioritise and stick to the top problems only (that wasn’t that easy for some!). We ended up with 4 categories of problems. That’s a good start for legacy product roadmap!

Task #2

We have identified 4 stages and 1 ‘other’ stage of home delivery process. Then we briefly discussed which stage would be most important to optimise and why. For example – improving an activity that happens 100 times a day is usually more beneficial than improving an activity that only happens once a day.

The task here was to assign all the printed screenshots to their stages. That sparked some good conversations and was definitely a good learning exercise.

Roadmapping - legacy-01

Task #3

When was the last time when you killed a feature? The usual pattern is that we keep adding new features to the product, but don’t spend any time on rethinking existing ones. I asked the team what our users do not need from the system any more (surprisingly there was a lot!). It was good to have our stakeholders at this point. They could explain the historical reasons for adding these features to the system and in most cases they agreed, that these are not needed any more.

Roadmapping - legacy-02

Killing features…

Task #4

The next task was to categorise remaining screenshots into two new sections: ‘Ain’t broken, don’t fix it’ and ‘Fix it!’. Here, we had to admit, even though the system is old, some parts of it are still pretty good and don’t need any attention.

Roadmapping - legacy-03

Leave it, fix it or kill it!

That was a lot for one meeting. We decided to come back to it the next day. In the meantime people could have a closer look on their own at issues discussed in this meeting.

Roadmapping part 2

We started fresh – ‘Ain’t broken don’t fix it’ screenshots have been removed from the board.

This time we were going to focus on business value and development effort needed for each of the features from ‘Fix it!’ and ‘Kill it!’ categories

Ready for part 2!

Task #1

We used post-it notes and T-shirt sizes (S/M/L) to estimate work required and business value.

The task was to assign stickers to the screenshots. This triggered a good discussion between the stakeholders and the team. We do have different perspectives after all…

business value
S/L/M stickers

Roadmapping - legacy-04

Estimation in progress

Task #2

The next task was to group features depending on how beneficial they would be and prioritise the groups. The best feature would be small development effort (yellow S) and large business value (pink L). Features not worth considering any time soon would be large development effort (yellow L) and small business value (pink S).

Roadmapping - legacy-05

All estimated, grouped and prioritised!

At this point we reviewed the P1 feature group – are they going to solve the biggest problems for our users?

P2, P3, P4… groups are now parked. They will be reviewed again when we are done with P1 group. At this time we will know the system better.

One thing to note is, that this is a product roadmap tackling user perspective only. There is more to do of course – sorting out technical debt is a great example.


Our stakeholders played a big part in this meeting – we could go in a totally wrong direction without them. They are also very happy to celebrate with us by taking all of us out for lunch and drinks, when the top 5 features are delivered!



Keeping stand-ups short

Stand-ups are supposed to be short. Sometimes, however, one or more team members start going into too much detail and the chat drifts off to a different subject.

When one of us thinks that the conversation should be taken offline or discussed with a smaller/different group of people – we take advantage of Mango rule – anyone at the meeting can simply say ‘Mango!’.

Just to be clear – it doesn’t mean ‘shut up’. It means – ‘this is off-topic, take it offline’.

This is a fun way of staying focussed on the subject and practicing team self discipline. My team loves it so much, that it has become a verb (i.e. Can we mango this please?). From time to time they are even ‘mangoing’ themselves…


Product Vision

As a Product Owner, you are in charge of the product vision. Whatever you come up with – people will most likely ignore it if they weren’t part of the process of creating it.

I’ve asked my team to discuss the product vision and come up with a statement that everyone would sign. We started from analysing product visions from some well known companies.

What others do?


Dude Logo NoStrapline_CMYK

“Make natural, delicious food and drink that helps people live well and die old.”



“Our vision is to be earth’s most customer centric company; to build a place where people can come to find and discover anything they might want to buy online.”



“We believe that we are on the face of the earth to make great products and that’s not changing. We are constantly focusing on innovating. We believe in the simple not the complex. We believe that we need to own and control the primary technologies behind the products that we make, and participate only in markets where we can make a significant contribution. We believe in saying no to thousands of projects, so that we can really focus on the few that are truly important and meaningful to us. We believe in deep collaboration and cross-pollination of our groups, which allow us to innovate in a way that others cannot. And frankly, we don’t settle for anything less than excellence in every group in the company, and we have the self-honesty to admit when we’re wrong and the courage to change. And I think regardless of who is in what job those values are so embedded in this company that Apple will do extremely well.”



“To create a better every day life for the many people.”


 “A computer on every desk and in every home; all running Microsoft software.”



“We will destroy Yamaha.” (in 1970)



“Crush Adidas.” (in 1960)


“To become the Harvard of the West.”



“To make people happy.”



To achieve sustainable growth, we have established a vision with clear goals:

Profit: Maximizing return to share owners while being mindful of our overall responsibilities.

People: Being a great place to work where people are inspired to be the best they can be.

Portfolio: Bringing to the world a portfolio of beverage brands that anticipate and satisfy peoples; desires and needs.

Partners: Nurturing a winning network of partners and building mutual loyalty.

Planet: Being a responsible global citizen that makes a difference.

Our product vision

In our meeting we quickly discovered, that it’s not that easy to come up with a statement that everyone would be happy with. That’s because each person had a different vision in mind… Good job we discovered it sooner rather than later!

As a motivator for a compelling vision, we kept challenging each other: imagine you meet the company founder and he asks Why are you here? What would you say?

Why are you here?

It was a very engaging and stormy meeting. For a while we even thought it might be not possible… We eventually agreed to one product vision, that everyone was happy to sign. Nothing good comes easy!

Our product vision

It was much better idea to do it together as a team, than leaving it to a single person. If team members don’t buy the vision it’s like living without a vision at all.


Communication skills

Communication is important. Not just for a Product Owner, but the whole team. Especially if it’s not a collocated one.

This is an excellent test for your team – a fun exercise that will uncover communication issues that nobody was aware of.


  • Time needed: 45 – 60 minutes (30 minutes for the exercise + time for discussion).
  • Number of people needed: 4-6.
  • Divide the team to 3 groups.
  • Groups A and C go to different rooms.
  • Group A gets a picture that only they can see (a child-like drawing works well).
  • Group C gets a pen and a sheet of paper.
  • Group B, called ‘Runners’ stays with group A for now. Their task is to communicate between Group A and Group C.
Communication exercise-01
Example setup

How it works:

  1. Group A and Runners discuss what’s on the picture. Runners can ask any questions they want, but they can’t see the picture and they can’t take notes. Group A can see the picture all the time.
  2. Runners move to Group C and convey the information.
  3. Group C draws a picture based on what they are told. They can ask additional questions about anything.
  4. Runners come back to Group A to ask for more details.
  5. Steps 2,3,4 are repeated as many times as needed till the time is up.
  6. The person facilitating the exercise should spend some time with each of the groups, silently observing.
  7. At the end – ask the team how well they think they performed.
  8. Show both pictures to everyone and discuss. What went well, what could be improved? Any actions?

Some things to pay attention to:

  • Does the team start from the big picture or details?
  • Does the team optimise the way they work during the exercise?
  • Is the team aware of time and how fast they are progressing?
  • Is the team focussing on the most important elements?
  • What assumptions are made?

How my team performed:

Screen Shot 2015-12-31 at 17.36.00
Original picture
communication exercise
Drawn by the team

What we observed:

  • The team jumped straight into details. Only 10 minutes into the exercise they discussed proportions of some key elements.
  • Runners split after the first exchange to save time. They didn’t however communicate between themselves, which caused asking the same questions twice. Surprisingly, they sometimes got different answers to the same questions, which required extra communication.
  • Group A also split, so they could deal with Runners separately, which resulted in one member not knowing if the horse was going to be present on the team picture at all at the end of the exercise.
  • The team didn’t plan the execution for the time given. This caused rushing at the end and asking for extra time to complete.
  • Some key elements were described in much detail, while others were very basic.
  • An assumption was made that characters on the picture sit at a table. It was quite quickly rectified though.
  • The overall result was good, but the team thought it was worse.
  • The team enjoyed working together and they want to repeat the exercise in a few months time to see if they can perform better.
  • The team is proud of their work.

It was definitely great fun and a good learning experience for the team. Try it yourself.