Scrum vs Kanban - Which one takes care of your well-being?

Heard from a few channels (Twitter, LinkedIn, etc.) that
test engineers are getting burnt out because of the
agile methodologies and continuous delivery.

While Kanban has WIP restrictions to make sure that
we don’t take more than what we can, Scrum does not
seem to have anything like that. Although Kanban is
continuous, it does not have fixed delivery time pressures
like Scrum.

Which one do you follow at your work? How do you find it?

Share your thoughts, please! Thank you.


We are in the process of doing a deep dive at the startup where I work into what kind of agility will work in our context.

Scrum ceremonies + Jira is our starting point, so we are going to explore, as a minimum, actual Scrum, XP and Kanban, as well as looking at the Agile manifesto to ensure that we understand values above all else and then find a way that works for us.

Phases like testing bottleneck and gatekeepers are those that we will seek to ensure we don’t come across.

Essentially, if anyone in the team is burnt by the ‘methodology’ being used, then the team need to look at that and own it and any changes going forward. It has to involve the team.

I don’t mind Scrum when it’s properly done, but everyone needs to understand what it is, why we do things and that the team can change the way it works.


It’s wonderful that your team is experimenting with the various processes.

Agile manifesto is a very good place to start, and then branch out to the various processes.

Note down relevant data, and prepare ‘before’ and ‘after’ scenarios during each trial, so that you get a feel of which one worked for you better. A/B testing between two methods will give a lot of information.

While I agree that it’s always the people who eventually take care of things at the end of the day, frameworks need to have structures in place for taking care of human well-being.

All said and done, one needs to be diligent about their own well-being and take care of themselves.


Both scrum and kanban can create burnout in my view as it’s never ending!!!

Has anyone got any tips on how to prevent it?

I’ve noticed that doing a mix of things sometimes helps - maybe one sprint you do product and bug fixing, next you focus on tech debt. I find the pressure comes from delivering new things in the product and it can be constant. It can be a battle to fight for other important matters.


It’s also important for managers / leaders to take care of their people. This is my number one priority of taking care of my direct reports before product.
Happy people = great product


Setting and managing customer expectations low on delivery can help.

I hear a lot of teams going crazy on delivery whereas not
not building real value for the product! Yes, this is happening,
and has to be prevented.


Also, someone told me that attaining simplicity in the process leads to project/product simplicity, and hence avoid burn-out. These were the resources I was given. You could do further homework/research and find out more information. And, do feel free to ask questions if you have any. We can discuss.

  • Clean Code: Martin
  • The Lean Startup: Ries
  • The DevOps Handbook: Kim et al
  • Toyota Production System: Taiichi Ohno

These might be developer-oriented, but testers could learn best practices from these too.
Take a look.


Regardless of methodology, style or tools that are used, there is always burnout.

If there is Kanban, some people will always break WIP limits, adding pressure to themselves, or the wider team. This could be individual contributors, or leaders external to the team who want to reprioritise independently.

Scrum can bring it’s own stresses too. These aren’t necessarily problems with the idea of the methodology, but the way it’s implemented, if individuals within teams, or teams within larger teams aren’t aligned.

Chris’s organisations processes sound an excellent way forward. My question is, how comfortable are people in raising their concerns with their organisations, so they can be addresses?

And how frequently does this happen, so that problems are addressed rapidly?

This might be easier in smaller businesses, where you can create your own change, without upsetting the apple cart.

Equally, larger orgs might have the processes in place already to handle this, but just operate more slowly, due to their sheer size.

Individuals might fear that they cannot make change in such an organisation, even at a granular level.

For me, it’s about creating an environment where people can say no, where they can say they aren’t enjoying the workload, and that they aren’t feeling good.

Burnout, for I have lived this, is both physical and mental. And quite often it will also be a problem that is external to your organisation that you can’t control or manage such as.

  • The mental or physical health of a team member

  • Some challenging life event, such as a birth, bereavement or other personal matter.

The question is how does the organisation respond to such things? Do they let go of that person, and wash their hands of their part in the problem? Or do they adapt to the needs of that individual, so their place in the team isn’t jeopardised, and their skills and thinking are retained.


Burn-outs could also happen when a person works in the same technology/field for a very long time and does not enjoy it anymore, or needs a change.

In software, most of the work is mental, so mental well-being has to be taken care of.
If physical circumstances like workplace environments, commute, etc. are not supportive, it adds up to the stress.

If the processes that we follow are just throwing work at us irrespective of how the person is feeling at a point of time, it becomes very difficult. That’s why I started the discussion.

Some thoughts:

  1. How to make the methodologies inherently care for the individuals (as a first step)?
  2. How can we learn to say no when it is not possible, when the methodologies rules are broken? How can the organisation/HR support that?
  3. How ‘continuous’ should be ‘continuous’? Will there be breaks?

One of the most imporant things in work is sustainable pace. If the pace is too high, then you get burnout.

In one company a manager asked the scrum master how much he could deliver. He answered with 7 or 8 stories and handling of all incidents in one sprint. The PO had to set the priority right.

Key ideas:

  • make small stories which can be done within 2 days. If they are too big, then slice them to the right size.
  • use Kanban to reduce the Work In Progress or WIP. This lead to pair programming or even testing by the developers.
  • use four hours in the 40 hour work week to learn. There might be a better way of programming or testing outside the company.
  • share knowledge in the knowledge management system.
  • get support from management for a normal working week.

Other ideas:

  • get sales managers involved with the developers to get realistic estimates. Notice that these estimates cannot be used for tight deadlines. There is still time needed for incidents and other features.
  • use feature toggling. A feature can be added to a service or product, but it can only be activated, when paid for. Feature toggling can also be used to add incomplete features. They can be activated when ready.
  • if there are multiple POs, then they have to decide together before the planning session.
  • have a look at the talk of John Cutler, how to break free of the Feature Factory:

Yes!!! This is spot on! It’s all very circumstantial. No one’s situation is the same, but after 20 years in testing, I am/was feeling a bit exhausted by it.

Learning all the time, yes, but not always the right things, or in the right way.


I’m intrigued that it’s the test engineers that are getting burnt out, which seems to imply the rest of the team isn’t. Which suggests the teams arent’t really a team: they’re not in it together, one of them can lose while the othes still win.

I think both Scrum and Kanban address this. Scrum tells you that people not part of the team can only address the team as a whole. So it can never be “Why did testing take so long, tester?”, but only “Why did it take so long to get this done, team?” Kanban focuses on pull and has WIP limits to prevent developers from piling up work in the “to test” column.

In my experience it’s the stakeholders/managers that can make a big difference here. If they present a number of outcomes they want to achieve with the team, you’ll get a very different dynamic than if they present a list of features they want to have delivered.


Didn’t say ‘only’ test engineers get burnt out, but since this forum is for test engineers, I addressed that way.

Not sufficient for Scrum to just address the team, but has to have some checks and balances in place like Kanban WIP to make sure that people don’t commit/take more than they can. Is there any?

Contents of your final paragraph is agreed, i.e. “outcomes over features”.
More specifically - “Product value over delivery/frequency while everyone is having a healthy life.”.

1 Like

In Scrum it’s the Developers (members of the Scrum team) that decide what goes into the sprint planning, so that does give them the power to prevent themselves from getting burned out. (Plenty of ways for an organization to pressure teams into putting too much in the sprint, though.) On the other hand, I believe it was Jeff Sutherland who said that if a team makes their sprint goal more than half of the time, they’re not being ambitious enough. I think it’s hard to create an organization where you can set things up like that in a healthy way.


We started with Scrum from the Trenches years ago and added the hard rule of not allowing more than 3 Stories to be In Progress at the same time for a 7-person team. I agree with most of what has been posted so far. The whole team (testers included) needs to agree on stories in a Sprint. The more of the company/organization that buys into the process, the better. More predictable dates, fewer bugs, less burnout.


Some rants in random order, based on the first things that came to my mind…

It’s not Scrum or Kanban or whatever other processes that puts pressure on Test Engineers.
It’s their managers and peers, and the testers themselves.

As a Tester you work for a manager who pays you to do whatever he thinks or wants of you - unless his mind is steered in a different direction. It’s not always that the tester agrees or feels he’s appreciated or making a difference, or has a reason to work for them…
The manager can enslave a tester into: doing useless things, not being challenged, doing the opposite thing of what the tester would want, staying overtime, being the bottleneck, taking all the risk of all the other broken people and processes, being a gatekeeper, being a documentation writer, doing technical support or writing a manual, developing and managing a separate automation checks product on their own, manage environments, steer business and help them create product specifications/tasks, etc…

The testers, even the good ones, are weak at showing their work and talking about it.
So they are easy to be pushed over and be told what to do without being considered much.
The quantity of testers has increased but the quality of the testers has decreased over time.
So the testers are afraid to argue, the managers are not afraid to replace them with another badly paid tester.

And this is made worse with these new methodologies of software development where the risks and decrease of product value are not assumed by managers anymore, but shifted down to the workers that have to push feature after feature in production.

1 Like

One interesting thing on what you wrote about “testers are weak at showing their work and talking about it”. Why is this? Can’t they equip themselves with organized data points, metrics, etc. so that they can confidently talk about their work?

The other points are subjective. I have seen highly paid and respected testers. Their morale is also very good.

1 Like

Yea I came to say much the same as others. No framework takes care of your wellbeing, because these frameworks like scrum and kanban and whatever else people use, are primarily built and sold as ways to work faster and improve ‘productivity’. Only people care for wellbeing, either their own or that of others around them. No framework, no business methodology or anything else whose aim is to make you go faster, is ever going to prioritise your health. Uh, in my opinion. Which is not an expert opinion, but yano open forum and all that. xD


Some additional thoughts from @thomas.binns on Twitter


The ‘However…’ part practically does not happen as per many people who commented here, because organisations try to push as much as possible to be implemented.

As far as ‘Poor management’ is concerned, there needs to be a mandate to enforce good management. Let’s see how that can be done.