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.