The ‘Zone of Acceptance’

One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.

The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job.  This can relate to tasks, overtime, meeting attendance and more.

In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours.  This is a confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours or core responsibilities.

However, when you move to agile it becomes much harder to deal with.

As an aside, in my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife with very matter of fact reply – That’s your job.  I don’t doubt that it is, but it is a hard line, if I want to challenge it I can, the responsibility is clear.  But conversely my behaviour in a different situation is far harder to manage. My wife may ask me to change our daughter’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I very rarely volunteer.  I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying so.  She can ask on a regular basis but that in itself undermines the equality and self-organising nature of marriage. The reality is that she is not asking me to take responsibility, nor is she demanding assistance, but my help is appreciated.  What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support.

The same becomes true in a Scrum team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that to a tester” or similar comments, they can be challenged. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged.  They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the Sprint to avoid picking up a task that doesn’t fall into their zone of acceptance.  This behaviour may not even be visible, a Scrum team can actually be very productive forming mini-silos, but that doesn’t make it right.

I see the role of a Scrum Master to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and be active in meetings, to volunteer to write documentation and present the Sprint Review, and to challenge those that don’t.

“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code itself.  And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries.

By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing and development are very different skills and expertise in either should be valued. But my view is that the comparison of skills needed for a sprint will often form a huge amount of overlap. If a product or sprint is a puzzle, chances are that there are a few parts that require specialist ‘Blue’ or expertise in ‘Red’ skills but the majority of the work is shades of ‘purple’ something that does not require expertise in either.

purple jigsawBut now what? We understand the problem, we know it is hard to spot and hard to challenge, so how do we expand the zone of acceptance?

The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognise it as a problem. Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than for the easy way out.

One team I work with identified this themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”

have I done this before

The idea was that when selecting a task to do the team member would stop and think: First whether they were taking a task that someone else could take and learn that task – or maybe they could pair and teach someone else; and secondly is this the next best task for the sprint or am I taking an easy option?  It is a written reminder and a challenge, and a challenge I’d encourage the other team members to make.

This barely touches the surface of this particular problem, and I’ll no doubt come back to it, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team.  And more significantly for this to be supported and encouraged by the team; the Scrum Master and the organisation.

What makes a good ‘Story’?

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable


Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.


A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.


A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.


A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation.


Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope.


A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive.

Backlog Refining Crib Sheet

Purpose of backlog refining:

  • Prepare stories for planning
  • Provide Product Owner with a rough estimate to aid their planning
  • Breakdown epics into manageable stories
  • Verify stories take us towards our goal and fit with our vision.
  • Identify Spikes


Refining should happen for at least 2 hours each sprint to stay on top of the backlog and ensure that there are sufficient stories estimated to be ready for planning – preferably a number of sprints ahead. (early in a project more time may be needed to get ahead)


  • Product Owner
  • Scrum Master
  • Entire Development Team

Before you begin

Product Owner should order backlog by his current perceived priority.


The Agenda is the backlog, move through the stories one at a time estimating or breaking down epics until the timebox has expired. (or all stories in backlog are estimated)


The Scrum Master (or designated facilitator) should ensure that the meeting is time-boxed. Refining is tiring and has taken us away from the current sprint. Keep to the allocated time and schedule another meeting only if it is necessary.


The Scrum Master must ensure the discussion remains on topic. If a discussion is getting into deep detail on the solution it is likely you are off topic. The goal is to give a rough relative estimate, keep discussions to a high level. If the answer to a question wouldn’t alter your estimate you probably don’t need to ask it.


There are a number of techniques for estimating PBIs, some teams use relative story points, some use T-shirts.   The value in the estimates is to the Product Owner and not the team – although there is some indirect benefit.

Story estimates should not be confused with Task estimates which occur at Planning Sessions.   Estimates should be of the relative size compared to other stories (it is not a measure of complexity). Many teams find it useful to identify an initial series of stories to use as your benchmark, or to create a datum to guide estimates.

An proper estimate is the relative size of a story to meet the definition of Done, including any requirements for documentation, testing and delivery – i.e. the package not just the coding.

Note: Estimating is tough! But it is not unique to Scrum, there are dozens of books on estimating software development. Scrum takes a view that estimation by a cross functional team is better than estimation by a single individual.

Story Breakdown

The refining meeting will often identify ‘Epics’ or stories that are too big or complex to estimate or to fit in a single sprint.  A skilled ScrumMaster can help the team breakdown stories into smaller slices that still have business value, it may be necessary to arrange specific story-writing sessions for some of the more tricky stories. There are a number of different techniques that can be used to break down stories.

Note: Story writing is tough! It will take time to get used to story writing and to find a level that suits the team, it is an acquired skill, and there are many techniques. A good Scrum Master may make the process a little easier.