Acceptance criteria – an easy way of defining scope

Acceptance criteria are a straight-forward way of describing, what needs to be in place before a task can be marked as done.

You might have experienced the following situation: you are in a refinement meeting and you just finished discussing a certain task. Now the team is about to estimate the effort of the task using planning poker: The poker cards for estimation show values between 3 and 13 story points!

So some people in the team think the task is more than four times as much effort to implement than other team members.

Discussing the estimation difference the team realizes, that team members had a completely different scope of the task in their head. That’s why there were such big differences in the estimation.

Unclear scope of task

I have been in many discussions, where people talk about what is the scope of a certain task. Although the description of the task is long and detailed, it is not clear what exactly needs to be delivered as part of the task.

This is especially uncomfortable, when the discussion is started during the sprint by the person, who is working on the task. Is this also part of the task?

When somebody creates a new task in the backlog, then this person has his own view on the topic. Sometimes the description is just 1 sentence and sometimes it is a whole page. Coming up with the right amount of description is not easy.

Problem of task description too short

When creating a task some people try to keep the description of the task as short as possible. They think that only the members of the team have to understand the scope of the task. And as the team will discuss the scope of the task in a refinement meeting, the details will be talked through anyway. So there is no need to have a detailed description, right?


Not all people are always present in those meetings, team members might be on holiday or are just not paying attention. Or it is also completely normal that people might forget about some details of scope discussions.

Therefore writing down the most important things in the task description is clearly a must for a proper backlog item.

Problem of task description too long

Then there are some people, including myself, who tend to write too long descriptions of tasks. The idea is to make the scope of the task understandable to everybody, even for non-technical people. This results in a long text, explaining the purpose, dependencies to other teams, things, which are out-of-scope, etc.

The problem is, that it is not clear what is part of the task and what is just there for clarification. Different people might interpret the description differently, because they have different backgrounds. And some people might not even read the description, because it is too long.

Finding the right balance of clear-enough description versus too-detailed description is not simple.

Adding acceptance criteria to a task

On top of having a title and a description, you can also add acceptance criteria to a task.

Acceptance criteria is a list of conditions, that a software must satisfy to be accepted by the stakeholders.

They define what a software should do, without specifying implementation details. So they don’t state how the software should do it, but only what the software should do.

Acceptance criteria should be relatively high-level while still providing enough detail to be useful.

They should include functional criteria, non-functional criteria and performance criteria.

Functional criteria

Functional criteria define how the software should work. It define the business processes in a software. For instance “the user can search servers by brand and type“.

One format for defining functional criteria is the Given/When/Then format:

Given some precondition When I do some action Then I expect some result.

Non-Functional criteria

Non-functional criteria define conditions for non-functional requirements. For instance, “the search button complies with the design of the search button on the front page“.

Performance criteria

In case performance is critical, then adding criteria defining performance thresholds make sense. For instance, you can add requirements for the maximum response time of a certain API call.

Benefits of acceptance criteria

Acceptance criteria make it clear in just a simple and usually short list of conditions, what should be done as part of the task. Therefore they are very helpful for the team to understand the scope of a task.

You can see the benefits of acceptance criteria during refinement meetings. Everybody is on the same page, when it comes to the estimation of the task.

Next to that, acceptance criteria are also very helpful for the tester. They make the job of the tester a bit easier, because he/she has a starting point on what needs to be tested.

Disadvantage of acceptance criteria

The downside of acceptance criteria is that everyone might rely on that list made by the creator of the task, without rethinking if the list is correct or complete.

If you don’t have acceptance criteria yet, then just give it a try for a few sprints and see how it goes.
In my experience it helped the team to make tasks much more clear, with just a little bit of more effort during the creation of the task.

Ok, that’s it for today.

I’m curious if you define acceptance criteria for each task and whether you find them helpful or just overhead. Let me know in a comment!

Stay tuned and until next week. HabbediEhre!

Scrum does not work for us

Coming up with a good estimation for a complex task is possible – even if you don’t know the possible options to complete a task.

We tried scrum in our company, but it does not work for us. Our tasks are so complex and unpredictable, that a single task estimated for two hours might take even two weeks to finish.

Do you think like this as well? Or did you hear such arguments from other people?

Recently I went for a beer with my houseboat neighbor and we ended up talking about work. He is a physicist, works in research and has his own company. Actually, he is building a simulation software to simulate the behavior of certain fluids under high magnetic fields.

We also talked about scrum and he told me, that they try to use scrum in their daily job as well, but it does not work for them.

Everything they do is completely new. It is very likely that nobody else has ever done those things before. That’s why you cannot estimate or predict how much effort such tasks will take.

He said: “It can take two hours, or it can also take two weeks!”

This triggered me to think: where can you apply scrum and for which type of work does it not make sense?

Well, this question reminded me on the Stacey complexity model, which says scrum works for all complex tasks.

So, scrum does definitely work also for those type of tasks.

In fact, the real question to this problem is: Why is estimating the effort so difficult for complex tasks?

What is a complex task?

The reason why some tasks are considered to be complex is that it includes a lot of unknowns. You have no clue on how to accomplish the desired result.

You probably have multiple options to choose on how to solve the problem. And you don’t know, which one is the best.

Or, even worse, you might not even know, which different options you have.

Refinement meetings

So what you are going to do to make the path to the solution more clear?

First of all, discuss the task with experts. Those experts you can probably find in your team. Just plainly discussing the problem helps a lot to identify what exactly needs to be done.

In scrum those discussions take place in refinement meetings. In these meetings the whole team gets together to discuss certain tasks in order to get a rough overview of the effort.

Well, actually refinement meetings are NOT part of the official five scrum events, but a lot of teams have refinements (also called grooming sessions) to estimate the size of tasks.

Still, although the refinement meeting is not an official scrum event, the scrum guide describes the refinement as an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

In these meetings the team sits together and discusses what needs to be done and how much effort it will take. When the scope is clear enough for the team, then the size of the tasks are estimated.


The point of the meeting is to get a rough overview on WHAT needs to be done for a certain task. You should not discuss all the details HOW you are implementing it, but just WHAT needs to be done at a high level.

Do not spend too much time on discussing details, a healthy amount of uncertainty is fine. Clarifying the last bits and pieces can be done in the sprint planning meeting. The goal of refinement meeting is to get a rough estimation of the task size.

Anyway, for difficult tasks the team can discuss the different options to complete the task. And then the team decides, which path is the best and will be chosen.

For difficult tasks do not leave this decision up to the person, who picks up the task in the sprint. Try to find the best path together and avoid one person struggling to find the best option by himself.

This might save you from wasting a lot of time, because multiple brains more likely pick the option, which is really going to work.

When the possible options are not clear

Sometimes though you might be in a situation, where you cannot even identify the possible options for solving the task.

For such cases I think it is a good idea to create and work on an investigation task one sprint before you actually start working on the task itself.

The scope of the investigation task is to research the different possible options for the solution.

Such an investigation task should be time-boxed. This means, you define upfront, that you will only spend for example half of a day to research possible options. 

Time-boxing the investigation task helps to avoid spending too much time on the research. The aim is not to build a fully functional prototype, but just identify the options for a solution.

After you have completed the investigation task you should have an idea of the possible options. Then you can bring those options again in the next refinement meeting and the team can together discuss and decide, which is the best one.

If the team has identified the best path to go for solving the difficult task, it will be possible to come up with an estimate of the size. The estimation is done as usual with planning poker in the refinement meeting.

Let me wrap it up

Estimation of a difficult task is done during refinement meetings. There you define the scope of such tasks and you split it up in smaller, manageable parts.

This is done by the whole team together.

In some cases this is not working, because the task might be too complex. You might not know, how to solve it and which possible options you have for completing it.

In such cases, it helps to create an investigation task, where you spend a limited time to research different options for solving the problem.

After you have some more insights you share the knowledge with the team in the next refinement session. There the whole team will again discuss and estimate the task together.

Do you have refinement meetings in your team? How do they work out? Let me know in a comment if your team sometimes struggles with difficult tasks and how you handle it?

Ok, that’s it for this week. Take care and HabbediEhre!

Can you plan for operational work?

Planning operational work is difficult, because you don’t know at the time of planning, what and how many operational tasks you have to work on in the upcoming sprint. But a big part of operational work can be planned based on experience from previous sprints.

Operational work is quite hard to plan in a sprint, because it is very hard to estimate how much operational work there is going to be in the upcoming sprint.

The previous 4 sprints I was helping out as a scrum master in another team in my company, the CDN team.

Those guys have a couple of hundred machines, which they have to manage and maintain.

And naturally every now and then a machine breaks and has to be fixed.

But as you don’t know upfront, how many machines need to be fixed and how hard that will be, it is pretty difficult to plan such tasks upfront.

In the CDN team we distinguish between development work and operational work.

Development work is obvious: implementing new features. You can break features down in small, manageable tasks, estimate them in regards to the reference task and plan them in the sprint.

But operational work is a bit more difficult.

Operational work

Let me give you some examples, which we in the CDN team consider as operational work:

  • Maintaining the platform
  • Upgrading software on production machines
  • Extend capacity on a machine
  • Install updates
  • Handling incidents, when machines or services are down
  • Fix broken networks or network devices

These examples are quite different by its nature: some of them you can foresee, some other just happen unexpectedly.

That’s why you can classify operational work in planned and in unplanned tasks.

Planned operational work

Examples for planned operational work are upgrading software on production machines, extend the capacity of a machine or install updates.

Such kind of work you already know beforehand, that you have to do it.

Therefore you can estimate it in a refinement session and plan it in the sprint as usual.

Unplanned operational work

On the other side there are unplanned tasks, which you can not foresee at the beginning of the sprint. Unplanned tasks can be classified in two types, which I call here general unplanned tasks and exceptional unplanned tasks.

General unplanned tasks

An example for general unplanned work is for instance let’s say 5 incoming severe incidents on average per sprint. Such incidents happen regularly, you can not postpone them to the next sprint, but fix them immediately.

General unplanned work is based on experience.

You look at your incoming incidents in the past and you can extract some information on how many unplanned tasks happen per sprint on average.

Then you estimate the amount of effort it takes on average to complete such tasks.

Based on that estimation you can reserve some time in the upcoming sprint, because it is very likely that such tasks will pop up again.

Therefore you can create a plan for your sprint, which includes even tasks, that do not yet exist at the time of creating the plan. Based on experience you know, that such tasks will very likely appear and you have to deal with them in the sprint.

Exceptional unplanned tasks

But then there are also tasks, which happen every now and then and take a very large effort of the whole team to fix them.

For example a core switch breaks or any other outage of a very important component of your system occurs.

In such a case probably the whole team has to stop working on what they were doing at the moment and put all attention to that incident.

You can not plan for such type of exceptional cases.

And of course this has a big impact on your whole sprint. It is very likely that you are not able to meet your sprint goal, because a big part of the sprint effort had to go into fixing this incident.

But fortunately such events do not happen on a regular basis, otherwise you really need to work on a solution to reduce the probability of such types of incidents.

Anyway, if such an exceptional incident happens during the sprint and therefore you are not able to meet your sprint goal, you will have a very good explanation for the stakeholders.

I’m quite sure your stakeholders will understand that keeping the system up and running has a higher priority than implementing that new feature. They are getting that feature anyway, just a week or two delayed.

 Let me wrap it up

So you can plan for unplanned work based on historical data. You know from experience how much effort you spend on average dealing with operational incidents during the sprint.

Actually, you can include work for tasks, which do not even yet exist, in your sprint.

In fact, the majority of the unplanned work falls into the category of what I call here general unplanned work. Therefore most of the unplanned work can be included in the planning.

Only work, which I here call exceptional unplanned work, is not predictable at all. Hence, you can not plan for such work.

But as such exceptional work rarely happens, our plannings will be always quite accurate – and for the rest we have a good explanation for stakeholders.

What type of work do you have in your sprint, which you cannot plan directly during your sprint planning? Let me know in a comment and tell me if you think I missed something!

That’s it for this week. Have a great day and stay tuned. HabbediEhre!


Definition of story points

Story points are all about effort and only about effort. A story point has nothing to do with complexity or uncertainty of a user story.

The definition of story points is not obvious.

Many scrum teams use story points in their daily job, because they are better for estimations than hourly estimations for many reasons.

But it is not clear how a story point is defined.

If you ask google, then you get a couple of different definitions.

Continue reading “Definition of story points”

How to choose a reference task

A reference task is a certain task, which has a fixed amount of story points assigned, and which is used as a reference point to estimate other tasks. But how do you choose such a reference task? This post should give you a method and some ideas, how you can find a good reference task.

Continue reading “How to choose a reference task”

Why you should prefer story points over hourly estimations

Every now and then people ask “What is a story point?” And then somebody gives the answer like “A story point in our team is about 3-5 hours work for one person!” Did you hear this as well? Or did you even give such an answer to other people? I did! Continue reading “Why you should prefer story points over hourly estimations”