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.


Scrum or Kanban?

Done right – either Scrum or Kanban will work for an agile team. As a Product Owner I always leave the choice to the team, even though I do have a preference.

One of my teams, who initially chose Scrum, decided to give Kanban a try. The plan was to try it for a month and then retrospect on what suits us better. Every day we were collecting data in order to make a proper data driven decision at the end of the experiment.

Work in progress (WIP) limits

We already had a WIP limit for number of tasks (7) and decided to keep it as it was. Deciding on SIP (stories in progress) limit was not that easy however. The very first day, the team (of 8 people) automatically picked 6 stories from the backlog and were ready to start each of them(!) straight away. From my perspective they were completely missing the point. Less work in progress means more focus and less context switching, which is a silent killer of good quality. Here is a good video about why limiting WIP works.

We negotiated and ended up with a limit of 4 stories. Observing the team I realised, that there was an attitude change required as well. I witnessed a situation when two team members finished a story and instantly started picking a new story from the backlog, instead of checking with the rest of the team if there is anything they could do to help progress other stories.

NB: WIP limit is a limit, not a target!


We were not excelling in Scrum straight away. It took 6 sprints to deliver exactly the number of stories we committed to in the sprint planning meeting. To be fair, these were very first sprints of the newly created team, so we knew it was not going to be perfect.

image (3)

Why change?

What actually triggered the thoughts of a change, was the fact that the team was adding quite a lot of technical stories to the backlog. Some of those should really be part of the original user stories the team was working on. Questioning further, we found out that the reason for separating the ‘user work’ and ‘technical work’ was… the sprint end. The team wanted to mark stories as done, even though unit test coverage (or some other technical aspect) was not good enough. That’s not really a ‘done’ story, is it?


Initially the team kept working on many stories at the same time (orange bars on the chart below). This was making the cycle time of each story longer – very little was being completed (green bars on the chart). As soon as the number of stories in progress went down, stories were completed more frequently and the cycle time (and lead time) got shorter.

Screen Shot 2016-03-06 at 15.51.15


Another thing that improved when we switched to Kanban was the number of stories completed (throughput). The data clearly shows that the team started delivering faster than before.



Before deciding one way or another, we dedicated one retrospective meeting (we kept having retrospectives during the Kanban trial) to talk about what went well (or not) and how does the team feel about going ahead.


The new ‘data’ (post-it notes) clearly showed an interest in Kanban.

Some conclusions about Scrum:

  • End of sprint was causing stress to some team members and resulted in additional technical stories. However, a deadline was a good motivation for others.
  • Sprints mean predictability, but because we almost never completed all stories that we committed to, it was no use to me as a PO.
  • Some team members didn’t have anything to do at the end of the sprint, while others were rushing to complete their work (or create a ‘leftover’ story instead).
  • There are a lot of rules to follow and artificial deadlines.
  • Every sprint naturally ended with ‘lab days’ – a day and half when the team could work on anything they wanted or simply learn new things.

Some conclusions about Kanban:

  • We were going faster (which could be also a result of the team maturing).
  • Kanban is more responsive to changing business priorities, which is great from a PO perspective, but not everyone in the team can embrace uncertainty the same way.
  • Meetings only happen when we need them, and not because the calendar said so. Stories are groomed as we go along, demos happen when there is something to demo.
  • Stories are broken down to tasks only by part of the team, which is more cost effective, however perspective of other team members is missed.
  • Developers can focus on finishing a story, including unit test and any required refactoring, without stressing about the sprint end (let me quote one team member: ‘hack less to complete story on time’).
  • There is less work in progress.
  • The team missed their lab days because there was no sprint end.

Some of these points, like WIP limit or lab days, could be enforced in both – Scrum and Kanban, so they are not really related to the framework.


The voting was undisclosed. Everyone simply stood by the side of the wall, which described their chosen framework. This resulted in 5 people standing by Kanban side and 3 people closer to the Scrum side (in between actually).

Something to remember

Before you switch to any new framework – invest some time in communicating again what the change is about. I don’t think it was very clear in our team – we just assumed that everyone knew what Kanban was about. Surprisingly – we weren’t aligned and some people struggled initially.

Experimenting with different frameworks can help the team to uncover some issues, that even though not related to a specific framework, might have been not visible before.

In my opinion, Kanban is more flexible to work with, but requires more self discipline. I’d advise less experienced teams to try Scrum first.

More resources

1. Short videos comparing Scrum and Kanban:

Scrum vs. Kanban – part 1

Scrum vs. Kanban – part 2

Scrum vs. Kanban – part 3

2. A blog post from my other team, who uses Kanban from day 1.

3. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win – a great novel about Kanban in practice.


User persona template

What’s the benefit of user personas? Our most successful persona started working… the same day! Funnily enough, it was a segment we initially missed in our user research.

Albert’s story

Albert represents a segment of our internal users who are very costly to the company, even though it’s not the biggest segment of all. Kicking off exactly on the day of introducing the Albert persona to people from outside of our team, ideas for improvement started flowing from everywhere. We discovered very quickly, that with minimum effort, we can help most of the Alberts and save the company quite a lot of money at the same time.

User research first

This is very important. Before creating a persona profile, it’s crucial to do user research. I’d recommend to do both – qualitative (interviews) and quantitive (data) forms of research. The more, the better. And don’t stop just there.

Personas template

What to include in a persona profile? A lot depends on the actual characteristics, however there are some key elements, which I believe are absolute minimum. These are:

  • Name, surname, photo
  • Profile
  • Tag line
  • Goals
  • Frustrations
  • Motivations
“Tag line”



  • Goal 1
  • Goal 2










  • Frustration 1
  • Frustration 2

  • Motivation 1
  • Motivation 2

Download this template

Important parts of our personas are also:

  • KPIs they influence
  • A day in the life of
  • Software systems they use

Some tips

  • The Goals section is the most important part.
  • Make the surname representative of a feature within the segment.
  • High quality photos showing more than just the face and the real environment of the persona tend to work best.
  • Don’t segment your users based on demographics. User goals are the criterium for it.
  • Some demographics will however, make the profile more personal and easier to believe (“yes, it’s a human…”).
  • Not all personas are equally important. Decide on which persona is primary, secondary or excluded.
  • Quote your persona using the language they would use.
  • Give examples as opposed to being generic.
  • Try to fit  within 1 page.

Keeping personas alive

Even the best personas might not work if they are not communicated properly. Make sure you keep them alive – you can quote them in user stories within the backlog, display their profiles all around the office or even (like we did) order a life-size cardboard cutout! This might seem a bit strange, but it will definitely trigger a lot of conversations around user centric design.

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.


Bad ideas workshop

The plan for this workshop was to design an awesome dashboard for our users. We invited one of our most experienced users and printed a lot of examples to discuss.

Awesome dashboard1
Ready for the workshop!

Somehow, nobody really knew where to start. It is pretty obvious what a dashboard is, but what is an awesome dashboard?

Start with bad ideas

People might get paralysed when it’s expected from them to say perfect things. They might think of something good, but then they quickly think it was not good enough and all you get is silence… Ask people for bad ideas and they will deliver!

And this is how we started this workshop – by generating bad ideas or describing experiences with bad dashboards.

Awesome dashboard 2
Starting from bad ideas

Revert bad to good

All you need to do next is to revert the bad ideas to good ones. It might seem pretty obvious in our example of a dashboard – of course a dashboard should be ‘simple’, ‘well organised’, ‘self explanatory’ etc. Doing it this way, however, the good ideas get much deeper meaning and we understand why they are good ideas.

Awesome dashboard 3
Bad ideas reverted

A/B testing included

Thanks to our debate about bad ideas, our team paid a lot of attention to details. Probably too much, because we couldn’t agree to one solution. The team split to two groups and they both generated a good design each.

Awesome dashboard 4
Two great designs

As a Product Owner, I struggled to decide which way to go, so we decided to ask other users for opinion. For the next few days, my team paired up and interviewed a group of users – every pair had to explain both designs to a random user, making sure we ask different users every time. This was an excellent exercise – our users felt that they had influence on the product development and we learnt a lot about the users. Win-win!

Key benefits

  • Very easy to start generating ideas, no silence!
  • Deeper understanding of good ideas.
  • Better discussion with users, as examples are often involved.
  • You might discover current issues that nobody mentioned before.
  • It’s more fun doing it this way!

Retrospective on overrunning story

It can happen to any team – a user story that was originally estimated for 1 sprint, becomes a never-ending stream of unexpected issues. In our case – we spent 4 months(!) working on a story like that. Soon after, we dedicated one of our retrospectives for a discussion about what happened.

Story timeline

We invited everyone who wrote any code for the story and its stakeholders. Wanting to focus on the biggest issues, we time-boxed the session to 1h and worked with the diagram shown below – a sneaky timeline with 10 placeholders for biggest blockers. Initially the team felt like we didn’t have enough placeholders (bad memories!), but we discovered that it was just enough ).

Story timeline

Having top 10 blockers listed on the timeline, we ‘dragon-voted’ (see the little dragon stickers on the wall?) for the most painful blockers. The ‘winners’ were then discussed in details. We debated whether the problem was related to:

  • people
  • process
  • tools
  • anything else
‘Dragon voting’

Back in time

The next task was to… come back in time. The actual question was: “If you knew all what you know today – what would you do differently starting the story again?”. Or in other words: “Come back to the time when the story begun and start over. What do you do?”. That was a very good debate.

Upgrade or not upgrade – that is the question!

One of our big issues was upgrading legacy code to newer version of Java. That caused countless numbers of issues that we didn’t expect. Someone said – ‘We shouldn’t have upgraded to Java 8’. But – is this really the best solution? The legacy code would remain legacy and technical debt would keep growing. The problems we experienced would be delayed in time, but they would still happen at some point.

Could we have avoided any of this?

Surprisingly, we could not have. We could have made it less painful though. Our conclusions were as follows:

  • Talk to people outside the team.
  • Make sure that pre-prod environment is identical with prod.
  • Contact teams we depend on sooner rather than later.
  • Share the knowledge, i.e. as a ‘quick guide’.
  • Research more up front if risky decisions need to be made.
  • Always try improving the current process.


Each story that unexpectedly becomes a project should be celebrated when done. We reserved the last few minutes of this retro for a glass of Prosecco and a slice of cake. We deserved that! Also, it helped us to ‘upgrade’ our relationship with the stakeholders and make it feel less stressful.




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.




Stand-up format

We used to follow the the daily scrum ‘recipe’, so every team member was answering the standard 3 questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Any blockers?

It worked well to some degree – we basically confirmed that everyone was busy. It wasn’t always clear how much we progressed with the actual work – sprint stories.

New format

We have changed the format to go story by story (as opposed to person by person). The questions are now addressed to the whole team:

  1. What did the team do yesterday for this story?
  2. What will the team do today for this story?
  3. Any blockers for this story?

Key benefits

  • Stand-ups are shorter.
  • There is more focus, as only things relevant to stories are mentioned.
  • It’s easier to spot neglected stories.
  • It’s easier to spot people busy with other work, as they do not add anything to this conversation.

We know that everyone is busy. There is no need to mention every meeting at stand-up time. It’s better to focus on the actual contributions.

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!