Team burnout: risk created by leadership

Fengler discusses six factors of risk concerning team burnout: Leadership, institution, team, person, private life and target group. In this article I will focus on aspects for leadership, which push teams into team burnout.


Leaders and superiors create a big slice of the personal or team burnout cake, because they frame the context of how people work within their organisations.

Fengler names crucial features of leadership, which push teams and team members in despair: missing knowledge, weak implementation, conflict avoidance, unpredictability, control freak, boundary crossing, excessive demand, oppression of improvement initiatives, contempt for mankind as well as clique. 

Weak leadership

"Burnout" by driver Photographer, Creative Commons 2.0, Flickr

"Burnout" by driver Photographer, Creative Commons 2.0, Flickr

Constant hesitation of leadership influences teams strongly. Regarding a team this might result in intolerably waiting for improvement or decisions. Work cannot be finished or started. Sometimes even already declared decisions which are withdrawn or suspended and lead to waste.

Too often the team is missing support concerning important topics. Teams are not represented and nobody is available to defend team interest on an organisation level.

People feel manipulated and not taken seriously by appeasement. In the end it is the lack of perseverance, which demotivates teams and hinders their progress.

Furthermore sometimes leadership lacks courage to come to an unpopular decision, often because of conflict avoidance. If those kind of decisions are coupled to improvement initiatives, this leads to mediocrity. Teams and organisation get stuck unable to improve and the ethos of work degenerates further.

Overwhelmed self-organisation

"Team should decide" - no matter if competency is available or if the team is interested in the decision. No one cares if the team conflicts on the decision and tears itself into pieces.

Sometimes leadership is unable to deal with conflicts or missing will to take the decision. Then they pass responsibility to the team using the Trojan Horse self-organisation. Sometimes they even name it an act of virtue.

Especially if you work with agile methods and overwhelmed management, management delegates decisions into the team. The delegation of leadership or conflicting decisions often leads to chaos (even sometimes in very mature teams). Such kind of decisions might stress the team on a constant pace.

Sometimes missing competency is driving teams into mental overload. Sometimes majorities change within a team and decisions are challenged frequently. A lot of teams struggle with with a wrong decision and need help with an intervention. Worst case: a team takes a decision and gets overruled by leadership. 

In a perfect world, every team is able to handle every decision they get asked. In real world it's a long dusty road and a lot of team members like to be heard, but just want to make decisions concerning their own profile. For sure teams can learn to handle decisions, even wrong ones. Help them reflect on a regular base e. g. with retrospectives. Be sure it will take some time to earn maturity and endurance to questions theirselves and adjust.


Source (German only): Fengler 2015: Jörg Fengler, Klett-Cotta Verlag, Ausgebrannte Teams

When teams burn out

Is it possible that whole teams burn out? If you are following publications of psychology: yes, it is. Team burnout is characterised by the dimensions of the individual burnout (exhaustion, decreasing performance, estrangement) and within a team the loss of social cohesion.

Here are some characteristics concerning team burnout (based on Fengler 2015):

  1. Indetermination
  2. Consent without results
  3. Joy about failure
  4. Testiness 
  5. Hostility against other sub systems
  6. Refusal of reflection

Those characteristics are just an extract. Each of them does not reveal per se a team burnout. If appear in combination they might indicate a big risk of team burnout. So take care if some of them exist.

I often saw those characteristics, especially during a change of the way of work (e. g. an agile transition). If you are working with a new team it is usually easy to spot strange behaviour. Most often the characteristics were already in place, during the change they were revealed, reinforced or weakened.

In this post, to stay with the agile example, I will relate to scrum examples.

"Burnout 1",  Dave Wild (Creative Commons 2.0)

"Burnout 1",  Dave Wild (Creative Commons 2.0)


Tuesday, 11:27 a. m., retrospective: The team is discussing a pain point. Despite the pain the team cannot conclude consequences from it. There is no chance towards agreement. The issue silts up and does not get solved.

Consent without results

During the sprint: The team struggles with a well known issue, which the team already decided to fix. The issue and steps to solve it have been discussed and decided in a former retrospective. But no one takes a step ahead to fix it.

It's like the team behaves disconnected from its own reality, unable to maintain its own performance. A gap emerges between the team decision and the long-yearned-for adjustment. Those adjustments are forgotten, dissolve in apathy.

Joy about failure

During the sprint: A server crash, fall of number of bookings, important supply is missing - name it as you want - and the team is delighted. Sarcasm spreads. You hear "did you see how competent XY did this great work" or "if it is offline, at least nobody is able to argue about the usability - that's progress".

If the working atmosphere is soaked by poison, leadership should act. 


During the sprint: Thin-skinned, tension, vulnerbility - during a day team members hit the ceiling because of little things. The relationships between the team members are under constant pressure and worn down. The sense of belonging is hurt. Outside of the team room the enemy is everywhere expected. 

Personal contact shuts down. A testy silence spreads. Everybody is afraid of to start a talk. Collaboration sinks faster than a stone. In consequence work gets only partially done or slows down.

Hostility against other sub systems

Friday, 10:28 a. m., daily scrum: One team member is complaining about the poor collaboration of the other department, which are responsible for the operation of the application. Despite of several requests response is missing. The other team members also let of steam. A surprisingly heavy criticism gets uttered. The group identity and cohesion of the organisation gets lost. No wonder that especially component teams, which rely on collaboration, are hostile to each other.

Those refusal between departments is very common. Just to name the classic conflict between development and sales:

  • Development: "they know nothing but sell it"
  • Sales: "they cannot develop something in budget which works"

In case of a dysfunction look out for "win/loose" relationships.

Refusal of reflection

Wednesday, 01:43 p. m., retrospective: A pain point gets addressed. It's something about organisational scope which cannot be fixed by the team but puts it under pressure. From the observing position of a ScrumMaster it is quite clear: there is a problem. On the other hand the team insists that everything is normal, they deny the problem.

The elephant is in the room, still growing and the team decides to ignore and hack the problem as part of their job. It looks like everybody's got one hand tied to his back and nobody cares. In the end the team might loose its ties to the organisation and is no longer capable to get involved with the problem.


Estrangement destroys the binding towards the own organisation. Emotional retreat is consequence and health is affected negatively. If anger, resentment, fear, contempt or disgust replaces the joy of work then exhaustion and decreased performance might naturally follow, too.

Often people and their relationships are the only glue left that sticks people to an organisation. If this glue gets lost (cohesion) then everybody starts to work on his own, interaction vanishes. The risk of team burnout increases dramatically. The organisation might break apart.

Way out

You can use retrospectives, if you are facing consent without results, indetermination or refusal of reflection. For example you can support the team to stick with its decided actions. Furthermore you are able to show improvement or missing action. Asking in every retrospective about the improvement and value of each action with a starfish scale inquiry is a good idea.


You might evaluate your team concerning those questions or discuss them during a retrospective:

  • How sarcastically is our talk? (seldom, often)
  • Are even small tasks perceived as stress? (seldom, often)
  • The team atmosphere is bad-tempered? (seldom, often)
  • Missing follow up for decided actions? (seldom, often)
  • Conflict between other teams or departments? (seldom, often)


Source (German only): Fengler 2015: Jörg Fengler, Klett-Cotta Verlag, Ausgebrannte Teams

Managing portfolio with roadmaps and teams

If you are working with teams, assign products or project to them and want to structure your planning process on a higher level, you might consider using a roadmap for your portfolio level (I use the term product equal to project).

To give product portfolio a sound basis you might use a roadmap to visualise the load factor of your teams. Just give every team its own lane and assign the planned products to the teams.

If you are doing this for the first time, you might wonder on how much products in parallel your teams are working. It is reasonable to think about the reduction of product multitasking to increase productivity.

For those products you are not sure if they are worth working on them yet, you have three choices:

  1. Keep them unassigned (unstaffed), but put them on the "should be considered soon for implementation list". Those products should be discussed in a portfolio meeting.
  2. Put them on a parking lot, if you do not want decide soon about the implementation but do not want to forget about them.
  3. Kill them, if you don't want to think about them in the future anymore or if they will never get the priority to get capacity.
This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

Here comes a little more description about the used lanes in the roadmap:

The team lanes

Within the team lanes you assign products to the teams. As long as a team works and is planned on a given product no other product should interfere. I recommend you to set a work in process limit (wip limit) for each team. This should speed you up and reduce waste.


Each product which could not be staffed by a team stays unassigned. Unassigned indicates: you want to work on this product, but do not know how to stuff it yet. In future discussion these products might get development time.

Parking Lot

You've got a product which is interesting enough not to kill it but doesn't have the priority to be developed you put it on the parking lot. These products might be good opportunities but hard to realise in practice.


If you refuse to work on a product, kill it. This means throw it away. Do not bother yourself in the future with concerns or thoughts about this product.

If you decide about your product portfolio, share it. Communicate it and make it visible as much as you can. If you want alignment, people must know about your decisions and for sure you have to defend it against the drift of the daily business. You might provide guidance for people and create policies for them. If you want to read about an example, I recommend to read about "how an issue finds its way into development".

If you are working in a hierarchical organisation, management should support or communicate the decisions. If communication is not aligned chances are hight that your portfolio gets sacked. Or just to stick with Gojko Adzic:

If communication fails, everthing else is just painting the corps.



From the trenches: How an issue finds its way into development

This article covers strategic planning using a project portfolio approach and tactical planning including incident management. It's direct from the trenches of development and explains the involvement and planning between stakeholders and development teams.

To dig into it, we need to distinguish two levels of planning:

  1. The strategic level: priorities and roadmaps are planned here. Teams get allocated concerning these priorities. Usually we allocate one team one project at a time (wip limit equals one).
  2. The tactical level: iteration (sprint) planning is done here and we deal with urgent issues from projects which are not allocated (lower priorities). Iterations follow goals of the project which is currently in progress.

As said: we are working under the constraint of "avoid multi-tasking", so each teams only works on one product/project at a time (iteration/sprint).

Stakeholders of an allocated project are are fine, because they are on the development track. If the project is not allocated, stakeholders only have chance of capacity if the issues do not clash with the overall priorities from management. The best thing a stakeholder can do is to plan the issues two weeks ahead of each sprint, so that there is time to break down the requests to get them into the sprint planning during the tactical planning and align them with the overall goals and priorities.

Strategic level

Planning on strategic level means managing priorities on product or project level. This is done with the management and Product Owner team. The result of this planning is an allocation of each an product/project to a team over a given period of time. Other projects keep unassinged and others might be suspended on a waiting list (parking lot) or killed (won't ever be done). 

We use a roadmap for planning and communicating the plan.

The allocation implies the priority. Allocated projects are those ones under development or planned for development. Unassigned are those ones which will be discussed next time and are more likely to get development time, parking lot means that this project is out of development scope and killed projects are entirely removed from priorizaton process.

The strategic planning is an reoccurring meeting - at least every six weeks. 

Tactical level

Tactical planning is about which issues should be done in wich sprint and dealing with change and other (external) effects. This is where reality hits. Yes, there might be requests from not allocated projects like bugs or small improvements. Its the duty of the Product Owner to deal with this requests and not to violate the given priorities from management. Usually most requests are urgent, but not very important, so it is possible to defer those to avoid time slippage of the important project priorities. 

Planning and timing

During development we are working with sprints, which are iterations of two weeks. The scope of those two weeks is mainly fixed because we are focusing a goal. The planning of all issues happens during the first day of the sprint. So if a stakeholder is late with communicating his requests, chances are low that your issue will get important enough to switch scope with an already planned issue.

To avoid that and increase the chance to get those issues planned is easy: be on time. This means stakeholder need to communicate their issues at least one week before each sprint (depending on size of the issue), so that the team is able to refine the issues (break it down, get it ready, get it understood).


  1. The only person who is ordering the list of issues for the sprint is the Product Owner.
  2. As a stakeholder to get your issues on the planning list, the only counterpart is the Product Owner.
  3. Talking to development team members is about clarification, not planning. Stakeholders should not waste their time trying to sneak into a sprint. This only creates waste and delay.


Sprint Planning with: just in time decisions and negotiation

Some time ago I wrote about the Sprint Planning. I said that it’s the last line of defence of your Sprint. Why did I name it the "last line of defence”? Just because it is the last chance to get things out of the way which are not ready for development or blocked. What if the last line is under attack and there are some requirements you are not sure about to discard or give it a try. That’s the time when negotiation comes into play. You sit together think, talk, and test your ideas to tackle it down. Sometimes you get it and sometimes you won't. If you are still unhappy with the results of your discussion, you need to decide how to proceed...

Negotiation and just in time decisions

One thing to negotiate in a Sprint Planning is scope. Another matter is what function really means and how much function is required to solve the problem.

And sometimes there are even a few more decisions to make and unfortunately we are only at the start und need to decide a little bit later, when we can inspect what we built. I’ve got good experience with this kind of scenario:

You’ve got some kind of requirement and it is not obvious how to solve the problem because there are a few (1-5) tiny decisions which seem equal and cannot be solved by discussion. Cannot be solved by discussion means to me that even if we talk about it we circle around or thoughts or people get distracted during the discussion. At this point we give it a try and set expectations about how the decision should be made later on. In other words we postpone decisions, we decide them just in time.

Maturity and decisions

Sometimes there is the question if only real mature teams are able to do this. I would say rather no or yes. I’ve seen both mature and immature teams succeed and fail. To me it is worth to give it a try und to start with limiting the number of decisions to make and to scale how big this decisions are. Even more important to me is to talk about this decisions, to value them and make it a part of our process or to talk about it what went wrong and what to try differently.


Set the stage with a starfish reflection

© Nevit Dilmen CC-BY-SA-3.0, via Wikimedia Commons

Use this method to set the stage in your retrospective, if you like to get feedback about the actions started after the last retrospective:

Goal: is to connect to actions of the last retrospective and to reflect about it.

Prepare a Flipchart with a table. Each line represents a topic the team decided to try out in the last sprint. Add further columns to the table:"more of", "keep doing", "less of", "stop doing”. 

Now ask the team for reflection and let the team members vote on each row with dot one dot per improvement.

TopicMore ofKeep doingLess ofStop doing
Try out TDD oooooo
Try out one piece flow ooooooo

Use the feedback for a short discussion:

  • Why should we stop doing this?
  • Why is it worth to go further?
  • What is really in for us?
  • What is the effort and value?
  • Are our expectations satisfied?
  • Why do the opinions differ that much?
  • Did anything unexpected happen?

Take 3-5 minutes discussion per action.

Have fun :-)


Surfing on the learning wave

Surfing in projects

If you inspect something you will learn about it. Your learning will lead to new insights that will lead to action. Action needs to be inspected and new insights will rise new learnings and further paths to inspect. Sounds like infinite play of waves against the shores and sure it is.

If we take for granted, that we'll learn on the way while we inspect something - when we analyse something - then we cannot deny and have to admit, that the learning is something that changes reality. So staring at reality and learning about it rises the need to deal with change.

Analysing too much, before taking action on it, creates waste. It is not only the waste of missing feedback, to a greater degree I think it is the waste of not catching the insight and the learning. Not preserving the change seems like wasting the investigation at all.

Back down the big analysis change wave

Let's have look at the most project management techniques: Usually we plan, when we have the least knowledge of a project ever. There is huge front-up planning at the start of each project, so we analyse a lot. Makes sense? Yes maybe, but do we really preserve the learning we've created? Do we fully accept that we changed our view about the thing we investigated? Not sure, in most times I would say yes - if the chunk of change is small enough.

As I said: While we analyse we change our view at a lot of things. So with each analysis we need to manage more change. Again: the more we analyse, the more we have to manage change. So far the creation of a big plan, without handling the wave of change created by the analysis, leaves the learning and preservation of insights behind. Instead of making big plans which drown us, we should focus on small batches to analyse where we can cope with the change we've created. So we need to find a batch size so small, that we can cope with the change we created.

Making the drop

You are shouting "Coming down" when you are the first to drop into the change wave? Only few surfers are brave and skilled enough to survive the big waves. So why not surf on the waves big enough you are able to deal with. Even when there are always a lot of change waves following, as soon as the ocean bed flattens out:

A guy who is making the drop in a nice wave. Every investigation reveals insights, and those insights lead to a wave of change. Don't let the wave grow too big to withstand it.

At the moment we hand over our experience, means sending out our deliveries to customers and users, we create more change. Now change might increase more than linear, according to the batch size of done work and people involved. If we take feedback outside of the team into account, then there might be a good reason to move to an even small batch size of analysis to cope with this wave of insights and demands again. 

Making the drop - again

Now, how can we really make the drop - again and again? To me one answer is to work in small timeboxes, where each timebox represents a small batch size of delivery and a deadline. Furthermore I would arrange a framework around it, which is able to inspect and adapt. This framework should be able to deal with experiments and feedback: something like a plan-do-check-act cycle. Fortunately here is already something out there and they call it Scrum. Wanna try it?


PS: Socrates said: “understanding a question is half an answer”.  .. and I want to append: "the second half of answer will change the question".

Learn as you go - A scientific method

Are you stuck in defined industrial processes, lined up in dependencies while working on an undetermined goal? Do you need to try out what works and what does not because your goals are too fuzzy? Do you need to learn as you go to prove your theory with data?

Then you might try a scientific method.

Observations in science. By Marretao22 (Own work) [Public domain], via Wikimedia Commons

In science you do experiments. This means you observe something, then you make a guess about it and formulate a hypothesis. To prove your ideas you experiment and see if you can validate your ideas - you gather data: hits and no-hits. If it sticks, you keep it - if not you formulate another hypothesis, experiment and observe the result again. It is like: "Oh, the apple falls to the ground. If I toss a stone, it will fall to the ground. Toss the stone. Yes, stone falls to ground."

So a scientific method works like this: Observation, hypothesis, experiment and back to observation - closing the cycle in iterations. 


Observation is the start and endpoint of any experiment. You gather insights toward your work and the decisions which were made from the data you have collected. You measure, interview and study the work you are doing or the experiment you have done.


Once you observed the environment you want to improve you assume what might be the next right step to follow. Formulate it and set it as a goal. This kind of goals are rather fuzzy than predictable. Your goal needs to be proved. So you stop talking and start doing.


Experiments are about exploring your ideas. Nothing is perfect from the start, so you have to gather insights. You start with an idea of what the world could be and check out  how wrong and right you are. Important insights are discovered after the start. Exploring is like: Build, break it, build it again and tweak it - that's the way solutions are discovered.


Use small iterations to experiment different hypothesis. Adjust your hypothesis as soon as you got real data and reiterate to your goal. Go for fast feedback from your customers and users to generate insights. 

If you are looking for this kind of approach: Agile, e. g. Scrum uses this scientific approach.


Ready ready* for the hammer

Some time ago I've read lamentations about story readiness and why is it bad because of it is destroying the intent of user stories. First I was amused, later on I was afraid that people will take this for sure. I do recognize that there is truth in this post, so far that people still miss using conversation - direct face to face conversation - and sometimes the concept of story readyness is taken for specifying user stories too far in advance and detail. Let me revisit this statement later on.

What is story readiness?

Story readiness is an artefact of the team. It is a contract and a visualisation about the what the team needs before starting in order to deliver working software within a sprint. First of all it is an activity: The team decides what parts are essential to work before starting it: "what should we collect to work on stories in a flow state, okay let's write it down." Now the teams knows the important parts to collect within their environment and this is the most important part of it - knowledge and visualisation as baseline for improvement. Using this artefact and sharing it with the other stakeholders is an act of fairness: We show you what we need to start (sure not everybody is interested in, but this is not the point). 

Now we've made the rules and circumstances explicit, we know as a team what to ask, what is important to us, what are the cornerstones we have to get clear. The performance of any team is in exponentially proportional dependency to the state of the work you start and you should start the ready work. Using story readiness as a contract between product owner and team means you declare a last line of defence to deny work wich is not ready for development.

Revisiting it

The intent of a user story is face to face conversation about the why, the whereof the story. Story readiness deals with what should we talk about to get the story ready, what has to be in place, so that you can start. If you do not know what you need to talk about, the conversation might get cumbersome. As said an user story conversation is about the value the story should provide and a discussion about different ways of implementation the function part. Even if this happend perfectly, the team is all fine with the intention of the user story, defined functionality and everything they need to get the story done. What if the parts the team needs from outside of their circle won't be delivered in time? What if the last line of defence is breached, because the team took unready work into a sprint and is blocked - well you had a nice conversation, but still important stuff is missing and work won't get done.

A definition of ready is a tool to be used. For sure teams with a classic requirement engineering background tend to do much requirement engineering in advance than agile style, this might lead to waste, but not definitely. Sure a team might not feel responsible for making the work ready, then you might use the readiness to check what the team thinks it can contribute and work on the items which they do not consider under their influence. As a scrum master you got a nice tool to show your team and management where improvements can happen.

Still you as a team are responsible to get the work ready, you might use the story readiness as a contribution to your last line of defence, to deny work which is not ready for implementation and tends to block your delivery within your sprint.



By Photographer''' Isabelle Grosjean ZACC-BY-2.5, via Wikimedia Commons

"If I had a hammer and hit me on the hand - would I say damn this shit should be banned?

If I had a hammer and something hit my hand - would I say damn shit the hammer should be banned?

If I had no hammer and something hit my hand - would I say damn I need a hammer to be banned?

If I had no hammer and nothing hit my hand - would I say damn shit nothing can be banned?" 



PS: *Ready ready is a term borrowed from Jakobsen and Sutherland, "Scrum and CMMI - Going from Good to Great: Are you Ready-Ready to be Done-Done," 2009


Different projects in a sprint - Juggling with knives

There is often the question: Different projects in a sprint - does it work? The answer is either yes or no! 

Yes, it works

When you use sprints, you might use Scrum. Scrum is a framework. You take it and put the work in that frame a sprint is offering you. Once your work is in that frame, you can work on it, no matter if it you are delivering for one project or serveral. You might loose focus because the projects are tearing you apart, but as long as you are able to stabilise the priority of you work during your iteration there is chance to succeed. And you still got a ScrumMaster to support you.

No, it does not work

By David Shankbone (David Shankbone (own work)) CC-BY-2.5, via Wikimedia Commons

It will not work, if you do not put all of your work into that frame. Leaving work out of your sprint will lead to distraction and waste. Usually while there is work happening outside that is pulling your attention, this work is not weighted against the work in your sprint. There will be waste through discussions about priority and unfinished work to resume. On the other hand when there is to much ad-hoc work you will run into trouble too. Ad-hoc work is similar to work which is not framed - and yet a little bit different. A sprint is also under policy: do not disturb the people working. If your workplace produces too much ad-hoc work the process you've selected will be under constant need of maintainance, so the system will need other desire paths than your process might provide, unable to heal itself.

There is still hope

You can learn about your environment and work situation. Just make your work visible, put your work on a taskboard and follow its flow from introduction to done. Visualize the problems and impediments you encounter and improve around all mistakes that happen. It might be a hard road and it is worth it. Usually this is true: "Only what is visible can be improved."

Different projects in a sprint - it's like juggling with knives, it might work or it might hurt... 


Sprint Planning - The last line of defence

How to enter a development bastion?

Still teams get stucked because the requirements they work on are not ready for development, because questions have not been asked, key questions not been answered, stakeholders not involved and the most ugly part: decisions not been made. So a lot of teams have to start with rather poor sprint backlogs.

To be productive and have fun with your work, you want no distraction from you work. You usually don't like to be blocked because of poor decisions or no decisions at all. As a developer you are standing in the last line of defence, because if nobody decides, you will make the decisions. 


"In a fortification with bastions, the citadel is the strongest part of the system, sometimes well inside the outer walls and bastions, but often forming part of the outer wall for the sake of economy. It is positioned to be the last line of defence should the enemy breach the other components of the fortification system." (Wikipedia)

In the shield wall

Ivar’s shield wall had held, but I could well imagine the ferocity of that battle.
— The Burning Land, Bernhard Cornwell

Standing there in the last line of defence you as a developer take it as a bastion to defend your sprint from distraction and blockades. Ask questions, demand decisions, make decisions, share your insights and if planned work is poor, then reject unclear requirements or stories. 

Sprint planning is a tool to be used. On the one hand it is about telling stories to get a common picture or to plan your collaboration, on the other hand you might use it as a shield to protect your performance. If you use sprint planning als shield and sword, then you show that there is a responsibility about making work ready. Remember you are involved in making work ready and you have to play your part.

You might try to add some components right in front your last line of defence:

  • Try to get stories small, because small stories are easier to understand.
  • Get stories ready for development for about 1 or 3 weeks before a sprint.
  • Use estimation or grooming sessions to ask key questions. Remind people about your questions constantly (as a scrum master, be a mosquito).
  • Make teams cross-functional or involve the people who can provide information. 
  • Write down the essential parts of your stories which need to be solved before (make it explicit and visible). This might result in a definition of ready.
  • Reject stories in the sprint planning, to show that essential parts of your stories are missing (do that in a responsible manner). 
  • Visualize at a wall which stories are ready for development. A product owner might suggest, but the team decides.