The power of habit – executing tasks automatically

A habit is something that you do often and regularly, sometimes without even knowing that you are doing it. The great thing about habits is that you can train yourself to make yourself execute certain tasks regularly without even thinking.

Everyone of us has millions of habits, good ones and bad ones. And they are triggered by certain events in life.

For instance, did you brush your teeth today in the morning? You might not even remember that you did it, because it is a habit. You don’t even have to think about it, it is just part of your morning routine and triggered automatically when you wake up.

You almost need no will power to execute a habit

The great thing about a habit is that you almost need no will power to execute it. That’s why they are so powerful.

If you can make a task to a habit, which you know will help you on a long term, then you almost need no will power to consistently execute it.

For example, if you want to learn playing the piano and you make practicing it to a habit, then you don’t need any will power to get yourself in front of the piano to practice.

Or if you want to eat healthier and you make it to a habit, then you don’t have to spend your limited will power every day in overcoming the temptation to not eat chocolate. It will go automatically without even thinking.

But how do you create habits then?

Creating habits is not so easy, but if you do it regularly, then it is getting easier over time.

I was recently listening to the audio book “Superhuman by habit” by Tynan. I highly recommend this book to everyone, who wants to learn more about habits.

Tynan explains in his book that there are two phases to build habits, the loading phase and the maintenance phase.

The loading phase

In the loading phase you want to teach yourself a new habit. Therefore you have to execute the task every day in the same routine.

For instance, after you come home from work you play the piano for 5 minutes every day.

This requires a lot of discipline and you have to constantly remind yourself to do that. For example, you can set an alarm on your phone or put a sticky note on the piano so you won’t miss it when you come home from work.

In the loading phase it is very important to execute the task always, even though your motivation might be down.

If you will really miss it once, then plan your next day in a way that it ensures you will execute the task. Because if you miss it more then once, then you basically have to start over again with the loading phase.

The maintenance phase

After the loading phase your habit is part of your daily routine and you can switch to maintenance phase.

You have built your habit to an extend that it requires almost no will power anymore to execute the task. It is automated and you don’t even have to think about it anymore.

When to switch to maintenance phase?

In general you cannot predict how long it will take to build a habit. It depends on the person itself and also on what exactly you want to train yourself to become a habit.

To find out, whether you have successfully built your habit or not, you have to ask yourself following question: “If I stop the loading phase today, would something change?”

If you answer the question with “No”, then you have built your habit. If you expect yourself to fall back to the old routine within a few days or weeks, then keep on going with the loading phase.

More flexibility in maintenance phase

According to Tynan you can allow yourself to be a bit more flexible, when you have successfully built your habbit.

For instance, you can train yourself to eat no junkfood at all. During the loading phase you are, of course, not allowed to go to McDonalds for a burger. Such a loading phase might take up to several years to built the habbit.

Afterwards, in maintenance phase, you can still stick to your plan, but be a bit more flexible. You can allow yourself to break the rule every now and then, as long as it is only exceptionial. Let’s say, that you can agree with yourself that you are allowed to eat at McDonalds, but only on Sundays and with your friends.

Drifting off

Over time though, you are going to drift off from your schedule. So you have to pay attention over the coming month and years and take correcting actions when you realize that you have drifted too much.

Benefits of good habits

As I already mentioned, the awesome thing about habits is that they don’t need any willpower to be executed. You are executing them automatically without putting a lot of thought in it.

It is of course quite some effort to built good habits. But even if the loading phase will take several years, you will have this habit most likely for the rest of your life. So investing a few years is still only a little effort compared to what you gain for the several decades afterwards.

Until now I was only talking about good habits. But you can also have bad habits. You can do things, which are bad for you, but you might not even really notice doing it.

Destroying bad habits is a chapter of it’s own. I am going to talk about it in one of the upcoming posts.

For now, let me know in a comment, for which daily tasks do you want to built habits? Is there anything, which would require a short amount of time per day, but you still are not able to consistently do it?

Ok, that’s it. I wish you a great day. Stay tuned and HabbediEhre!

 

 

Will Power – Discipline can be trained

Will power, or you can also call it discipline, is the ability to control yourself. The interesting thing about will power is that it behaves like a muscle: it needs time to recover after you strained it, but you can train it to get more strength.

On the one hand side you need will power to overcome inner temptation and force yourself not to do things. Such things, which are bad for you, but you are so used to.

And on the other side, you need will power to force yourself to do things, which you know would be good for you.

For instance, you need will power to overcome the temptation to not eat sweets when you are on a diet. And you also need it to push yourself out of the couch and to the gym to get in shape.

It seems that people, who achieve a lot in life have a very high will power, otherwise they would not be able to achieve those things. For instance, athletes train every day, while for “normal” people it is hard to even go to the gym once or twice a week.

Will power is limited

Science found out in multiple experiments, that will power of humans is limited. Similar to muscle power, you have only a limited amount of will power per day.

For example you can lift weights only a certain amount of times until your muscles get tired. Then your muscles need some rest to recover, before you can use them again.

Similarly, you can stretch your will power only to a certain degree, after that you need some time to recover to gain back your strength.

I was recently reading the book “The power of habit” by Charles Duhigg. I highly recommend the book, if you want to know more about habits from a scientific point of view.

Anyway, in the book he mentions an experiment, which has been conducted in the 90s.

The experiment

76 undergraduates participated in the experiment. They were told, that the goal of the experiment was to test taste perception. But his was not true, the real goal was to test will power.

Cookies vs radish eater

Each of the participants was put in a room with a plate of food. Half of the plate was filled with warm, fresh cookies and the other half was filled with radish, the bitter vegetable.

Then the scientist told half of the participants, that they are only allowed to eat the cookies and the other half was only allowed to eat the radish. Then the scientist left the room and the participant was on his own.

Of course, the cookie eater were in heaven and the enjoyed the fresh and sweet cookies.

The participants assigned to the radish were craving for the cookies, but they had to stick to the bitter vegetables. It took them a lot of discipline to resist the warm cookies. Ignoring radish is easy, but ignoring the cookies requires a lot of discipline.

The unsolvable puzzle

After a few minutes the scientist came back to the room, removed the plate and told the participant that they need to wait for few minutes. The participant got a puzzle, which they should solve while they were waiting.

The scientist told the participant, that they could ring the bell, if the need something. Then the scientist left the room.

Actually, the puzzle was the most important part of the experiment. It was not solvable. When you try to solve it you will always fail and it requires a lot of discipline to try it again and again and again.

The cookie eater were very relaxed. They tried to solve the puzzle over and over again. They still had a lot of will power left. Some of the cookie eater spend more than half an hour before they rang the bell.

The radish eater on the other hand, were very frustrated and they rang the bell much earlier. Some of them were angry and told the scientist, that this is a stupid experiment.

After all, the cookie eater rang the bell after 19 minutes on average, while the radish eater rang the bell only after 8 minutes. The cookie eater spent more than the double amount of time to solve the unsolvable puzzle.

This means the radish eater had already consumed a lot of their will power when they were resisting the cookies.

Will power can be trained

There are a number of conducted experiments showing that will power can be trained. If you want to know more, than read the book, which I already mentioned above: “The power of habit” by Charles Duhigg.

You can train your will power, like you can do with your muscles. Training every day makes your muscles stronger and you are able to lift more weights.

It is the same with will power, training it increases the strength and the maximum of your daily will power increases.

Don’t rely on will power

I thought that successful people have a lot of will power, or discipline. Otherwise how would they be able to achieve all those things?

To my surprise it is not will power, that drives successful people. Will power is important, but the key here is to build habits.

Building a habit requires discipline, but when you have built one, then executing it requires almost no discipline at all.

For example, when you were a kid, then your parents probably always had to remind you to brush your teeth, before you go to bed. It required a lot of discipline by your parents to push you and build this habit for you.

Nowadays you probably don’t even think about that you have to brush your teeth before you go to bed. It just happens automatically and doesn’t require a lot of discipline. The habit has been build, executing it is easy.

Anyway, the whole topic about habits is a very big and interesting one. Therefore I will dedicate one of the upcoming blog posts to that topic.

Ok, that’s it for this week

The next time you come home from work with the plan to go running, but you don’t have any motivation at all, then remember that will power and discipline can be trained like a muscle 🙂

Stay tuned and have a great week. 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 scrum.org 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.

Commitment

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.

Courage

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.

Focus

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.

Openness

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.

Respect

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?

Wrong!

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.

WHAT, not HOW

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”