Netherlands biggest interest in Scrum worldwide

How interested are people in Scrum? Is it´s popularity growing or declining? What about the interest in Agile or DevOps?

A few days ago I stumbled upon the website from google, called, which tells you what people search for on the Internet using the Google search engine.

It´s amazing how the Internet works today. Google alone currently receives about 60.000 search requests per second! Yes, per second!

I was actually curious to see what people, who are interested in Agile and Scrum, are looking for.

So I clicked a bit around and found 3 interesting results, which I would like to share with you:

“Scrum” most popular in the Netherlands

It turns out that people from the Netherlands searched for “Scrum” the most compared to any other country in the world. I looked at a time range of the previous 12 months (November 2016 to October 2017).

Google Trends: Scrum

The numbers are calculated on a scale from 0 to 100, and represent a search interest relative to the highest point (for the chart in the middle of the picture) or relative to the location with the most popularity for the search term (for the list on the end of the picture).

A higher value means a higher proportion of all queries, not a higher absolute query count. This means, the numbers are relative to the size of a country and therefore you can compare a very small with a very big country easily.

The result is very interesting for me, because I (still) live in the Netherlands and I know that Scrum and Agile is big here.

But I didn´t know that people in the Netherlands are leading the ranking and have the highest interest in Scrum worldwide.

St. Helena and China are (to my surprise) on the second and third place in the ranking. I will revisit both of them in a minute.

If you compare the Dutchies to Switzerland and Germany, which are on the 4. and 5. place in the ranking, then the interest there is just about 50% compared to the Netherlands.

I expected the U.K. and the U.S. somewhere in the top places, but I found U.K on rank 20 and U.S. even on rank 25.


Another interesting result:

“Agile software development” most popular in St. Helena

If you are like me, then you might ask yourself: Where the f*ck is St. Helena?

I had to look it up in Google maps as well, it´s a small Island somewhere in the middle of the Atlantic Ocean. It probably sounds familiar to you as well, because this is the Island, where Napoleon was banned after he lost the Battle of Waterloo in 1815.

Anyway, there live around 4500 people on the Island and they are obviously crazy about Agile software development.

If you go there for holiday you probably find agile people all over the place. 🙂

Google Trends: Agile

As you can see in the graph, the popularity of “Agile software development” was quite stable throughout the year, but started to increase since August 2017 (until today November 2017).

So, either Agile software development is really getting more traction since the last 3 months, or google made changes in one of their algorithms.

This is just interesting for me, because the amount of page views on my blog increased as well. It actually follows pretty much the same pattern as above – quite stable throughout the year, and then a linear increase within the last 3 month.

So I thought, maybe the graph in google trends is actually caused by my blog?

Well. I wish 🙂

Anyway, here the last interesting result I found:

“DevOps” is very popular in China

Come on!


That´s weird!

Google Trends: DevOps

If you look at the numbers, then the Chinese interest in DevOps is way ahead. St. Helena again, on second place, has only 55%. And then we have India on the third place with only 40%.


But anyway, I think Google trends is a very interesting and powerful tool. And it is really fast.

It gives you insights in what people are searching for on the Internet using the Google search engine.

And the cool thing is, that Google gives you access to this information for free.

So have a look at it and play around. There are quite some nice features to discover.

Btw: if you were wondering why the graph has its minimum always at the same time in all of the three graphs, then I can tell you that people don´t want to know about Scrum, Agile development or DevOps at the end of the year. 🙂

It seems, like everyone is at home celebrating Christmas and New Year, and spending no time searching the Internet for these topics.

But that´s happening not only for these three topics, but the amount of queries in general goes down during these days.

If you want to look into this further by yourself, here are actually the links to the queries I used in google trends:

Ok, that´s it for today. Stay tuned and HabbediEhre!

Nexus – the scaling Scrum framework

Nexus is a framework, which builds on top of the scrum framework and is designed for scaling. It focuses on solving cross-team dependencies and integration issues.

What is Nexus?

The Nexus framework has been created by Ken Schwaber, co-creator of the Scrum framework.

Similar to the scrum guide, there is also the Nexus guide, which contains the body of knowledge for the framework.

It has been released by in August 2015.

You can find the definition of Nexus in the Nexus guide as follows:

Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.

The Nexus framework is a foundation to plan, launch, scale and manage large product and software development initiatives.

It is for organizations to use when multiple Scrum Teams are working on one product as it allows the teams to unify as one larger unit, a Nexus.

Scrum vs Nexus

Nexus is an exoskeleton that rests on top of multiple Scrum Teams when they are combined to create an Integrated Increment.

Nexus is consistent with Scrum and its parts will be familiar to those who have worked on Scrum projects.

The difference is that more attention is paid to dependencies and interoperation between Scrum Teams.

It delivers one “Done” Integrated Increment at least every Sprint.

New Role “Nexus integration team”

The guide defines a new role, the nexus integration team.

It is a Scrum team, which takes ownership of any integration issues.

The Nexus integration team is accountable for an integrated increment that is produced at least every Sprint.

If necessary, members of the nexus integration team may also work on other Scrum Teams in that Nexus, but priority must be given to the work for the Nexus integration team.

Event “Refinement”

In Nexus the refinement meeting is formalized as a separate scrum event.

In the cross-team refinement event Product Backlog items are decomposed into enough detail in order to understand which teams might deliver them.

After that dependencies are identified and visualized across teams and Sprints.

The Scrum teams use this information to order their work to minimize cross-team dependencies.

Event “Nexus Sprint Planning”

The purpose of nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint.

Appropriate representatives from each Scrum team participate and make adjustments to the ordering of the work as created during Refinement events.

Then a Nexus Sprint Goal is defined, an objective that all Scrum Teams in the Nexus work on to achieve during the Sprint.

After that the representatives join their individual Scrum teams to do their individual team Sprint Planning.

Event “Nexus Daily Scrum”

The Nexus Daily Scrum is an event for appropriate representatives from individal Scrum Teams to inspect the current state of the Integrated increment.

During the Nexus Daily Scrum the Nexus Sprint Backlog should be used to visualize and manage current dependencies.

The work identified during that event is then taken back to individual Teams for planning inside their Daily Scrum events.

Wrap up

This is a very highlevel overview about Nexus, you can find more information in the Nexus guide or in this nice introduction.

I am practicing Scrum for quite a while now, but I have never heard about Nexus before. Only last week I stumpled upon it on the Internet.

Therefore I also don’t know anybody who is actively using the Nexus framework in their daily work.

But from this point of view it looks like Ken Schwaber did a very good job again when defining this framework.

I hope that I will have the chance some time to work with Nexus in real life. Of course, for that you need to have the environment where it would make sense to give the Nexus framework a try.

Ok, that’s it for this week. Have a good day and HabbediEhre!

Scrum values – new section in scrum guide

The scrum guide, the official description of the scrum working methodology, has been recently extended with a new section: the scrum values.

Before we dive deeper in what the scrum values are about and what they mean, I want to give you a quick overview on the history of scrum, and especially about the history of the scrum guide.

Then it should be easier to understand the big picture, when and why the scrum guide has been created and updated over the years.

History of scrum

Scrum is now about 21 years old.

Jeff Sutherland and Ken Schwaber, the fathers of scrum, presented their paper “SCRUM Software Development Process” the first time in 1995 at the Oopsla conference in Austin, Texas.

But the name scrum was not their invention. They inherited the name from the paper The New New Product Development Game published by Takeuchi and Nonaka a few years earlier.

Scrum is used to solve complex problems. It uses an empirical approach and solves problems based on experience and facts.

Until today scrum has been adopted by a vast amount of software development companies around the world. But scrum has also been successfully applied in other domains, for instance manufacturing, marketing, operations and education.

History of scrum guide

Jeff and Ken published the first version of the scrum guide in 2010, which is 15! years after their first presentation of scrum at the conference. I don’t know why it took them so long nor what has been used by the community before that.

Jeff and Ken made some incremental updates to the scrum guide in 2011 and 2013. Together they established the globally recognized body of knowledge of scrum, as we know it today.

Recently, in July 2016, a new section has been added to the scrum guide: the scrum values.

The scrum values

Successful use of Scrum depends on people becoming more proficient in living following five values: commitment, courage, focus, openness, respect.

Let’s have a look at each of those values including the one sentence of description from the scrum guide.


People personally commit to achieving the goals of the Scrum Team.

I am personally very happy that this value has been added to the scrum guide and is now officially recognized as an important value for a scrum team.

It is a challenge to get the team to commit to the goal of a sprint, but it is a cruicial part in making the team successful.


The Scrum Team members have courage to do the right thing and work on tough problems.

People should stand up for their beliefs and for what they think is important to put the team to the next level.

People in a scrum team should not be afraid of though problems. They face even the thoughest problems and try to solve them together.


Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

People are not picking up work outside of the committed sprint. They focus on the work, which has been agreed upon in the sprint planning.

Everybody works on what is good for the team, not what is good for themselves. The goals of the team have a higher priority than the personal goals.


The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.

There is no hiding of facts or not telling the whole truth about what is going on. There are no political games played.

Everybody is honest about the problems they face and for instance explains why things are delayed to give the stakeholder insights of what is happening within the team.

Openness in the team as well as openness to the stakeholders builds trust and a better working environment.


Scrum Team members respect each other to be capable, independent people.

Respect is one of the key elements of building a good culture within the team and in the whole organization.

Treat people as you want to be treated!

Why has the scrum guide been extended?

How were those changes in the scrum guide implemented?

Ken and Jeff built a community around the scrum guide and they are running an online platform, called users voice, where people can make suggestions for changes in the scrum guide.

Other people can vote for those suggestions, but the final decision for making changes in the scrum guide is still taken by Ken and Jeff.

Wrap up

Today scrum is recognized as the most applied framework for agile software development.

The scrum guide plays a very big role in the success of scrum, because it is the first reference point for people wanting to learn more about it.

The newly added section containing the scrum values are a very welcome idea to improve the scrum framework even further.

I will definitely present those scrum values to my team to make them think about this topic and get a discussion rolling. Let me know, if you did the same and share your experience in a comment.

That’s it for this week. Stay tuned and HabbediEhre!

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!

Sprint Goal – Boost productivity by defining focus

Defining a sprint goal in the planning meeting helps to keep the team focused during the sprint and also facilitates collaboration within the team.

Do you define a sprint goal during planning meeting?

If you are just wondering what a sprint goal is, then continue to read this post, because I can almost guarantee that a sprint goal will help.

Do you struggle to make the sprint?

Does your team have problems to finish the tasks, which were planned for the sprint?

Are there some team members, who worked on tasks outside of the sprint, because there was no more task in the To-do list? And meanwhile some other team members were not able to finish their tasks, which were planned for the sprint?

Then your team does not have the right focus.

The team probably acts like a task is owned by a person instead by the team.

You want to be predictable

Stakeholders expect from the team, that they deliver what and when they promised to deliver.

If the team does not keep up with their promise to deliver features in time, then the team looks very unprofessional.

And of course, we don’t want that. We want great teams!

Fortunately, there are more important and less important tasks in the sprint. Some of the tasks have to be done to keep up with the promise you made and deliver the functionality.

Some other tasks are not so important and can be easily postponed to the next sprint. Not delivering those tasks does not have an impact on the expectations from stakeholders.

So there is kind of a priority of tasks within a sprint. Some of the tasks just have to be delivered. Some other should be delivered, but in case the team is not able to finish all of the tasks, it is better to leave those tasks behind and pick them up in the next sprint.

The sprint goal

The sprint goal describes what you wanna achieve in the sprint. It describes a state in which you want your system to be after the sprint is completed.

For example, the sprint goal of my team in the previous sprint was: “Having a Chef cookbook to automatically provision a machine for IPAM API in Live Replica“.

Let me explain, what that means: IPAM API (IP address management) is the product we are currently working on. And Live Replica is the name of one of our test environments.

Chef is a tool to manage your infrastructure in code. This means, you can write code – so called cookbooks – to define, in which state you want to be your machine in. With state I mean the software you want to have installed, firewall rules, environment variables, etc.

Anyway, the goal was to create a cookbook, which prepares all necessary components to install our application automatically in the test environment.

By the way: we achieved our goal 🙂

When and who

The sprint goal is defined from the team during sprint planning.

It is important that you set a goal, which is possible to achieve. It does not make sense to define a target, which you already know the team is not able to accomplish. Everybody in the team has to commit to it, it is a team decision.

When you define the sprint goal, then be specific, so there is no doubt what exactly needs to be in place in order to achieve the goal.

Make your goal visible

When you have defined your sprint goal, write it down on a sticky note with big red letters and make it visible. It should catch the attention of the team members and remind them about the goal.

This makes sure it is clear and obvious for everybody in the team, what the team wants to accomplish in the current sprint. This will help that everybody is aligned and the team works together with the right focus.

In my team we put the sticky note with the sprint goal on the scrum board. Every day in the morning at 9:30 we get together in front of the scrum board for the daily scrum. There we quickly update each other about what everybody did yesterday and is planning for today to achieve the sprint goal.

This helps us to keep the focus and work together towards the defined goal.

We also mark the tasks, which have to be finished in order to achieve the sprint goal. We actually just put a thick red frame around those printed cards to emphasize the importance over other tasks. So this helps to make it obvious to the team, which tasks have higher priority.

A sprint goal facilitates team collaboration

A great side effect of defining a sprint goal is that it facilitates the collaboration within the team.

If one member is done with her tasks and there is no more task in the To-Do list, then instead of adding another task to the sprint, she will ask other team members whether they need help.

And that’s actually exactly what we want.

I noticed that some teams have the mentality that tasks are owned by certain team members. The one who picks up the task owns it. The attitude in the team is like: if he is not able to finish his task in time, then it is his fault.

But the attitude should be: if we were not able to finish that task, then it is our fault!

If you have a defined a sprint goal, then this facilitates the team collaboration within the team and members help each other and work together to achieve that goal.

Ok, to finalize this post, let me tell you that I am convinced that having a defined sprint goal keeps the team focused and facilitates team collaboration.

So, if you don’t define sprint goals yet, give it a shot. It probably will not change the attitude of the team in just 1 sprint, but try it for 5 sprints and then I am quite sure you will notice a difference.

That’s it for today. Let me know if you think a sprint goal might be a good idea and you will try it. And if so, I am very curious about your experience to introduce a goal for each sprint.

So have a great day 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”

Core Scrum CHECKLIST – Doing real scrum?

The core scrum checklist is a great and easy way to determine whether you are doing real scrum.

The core scrum checklist is an easy way to find out, whether you are really doing scrum.

When I started in my new team we had all the scrum events in place – sprint planning, daily standup, demo session, retrospective meeting.

But it turned out we were still missing some important elements for really doing scrum.

How about your team? Is your scrum process really ok?

Verify with the following simple checklist!

Continue reading “Core Scrum CHECKLIST – Doing real scrum?”

Traditional vs empirical process

What are the differences when you implement a project using the traditional approach vs an empirical way of working? During a scrum workshop, which I attended recently, this question has been answered in a very descriptive and visualized way, which I want to share with you.

Continue reading “Traditional vs empirical process”