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!

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!

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!

 

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”