Why did Scrum.org redefine SLA to SLE if the whole IT market already understands this concept as SLA (and not SLE)?

I don't see it as a new concept, but a reframing in thinking. It's a conceptual difference between an "agreement" and an "expectation". The notion of an agreement brings to mind binding arrangements that, if broken, allow one side to take action. The concept of expectations are more about strong beliefs, and if you consider Scrum's emphasis on empiricism, beliefs rooted in past performance and things that are known. Consider that Scrum estimates work and forecasts capacity and the work that will be done, and doesn't commit to much (the only commitment is people making personal commitments to the goals of the Scrum Team). Moving from "agreement" to "expectation" fits the Scrum mindset a little better.

People can agree to anything, but expectations are built on evidence.

I see your point, but, SLAs can be seen as a kind of a promise made to the customer. Each service should have its own lead time to be delivered. "Inside" the lead time, there's the cycle time of the service.

Blockades can be calculated. It is an agreement that can also be seen as a commitment. Without it, it is not clear how to manage the customer expectations. Customers can also define it when they want performance characteristics of a service. You can also can set range of expectations for shipping the service.

For instance, you can set that a service will be delivered between 5 to 8 days. Customers will expect that. So, even though it is not the same concept, there may be some circumstances or organizations that both an agreement and an expectation could have the same meaning.

SLAs can be seen as a kind of a promise made to the customer.

What is this promise based on? You can't predict the future with certainty. Using the word "expectation" lets you focus on setting goals and collaboratively working toward them. You can expect to have work resolved in a certain time period, and if you embrace empiricism, you are basing that expectation on (recent) past performance and projecting forward to a short period of time that may be more clear.

The idea is to move away from promises and commitments that may or may not be based in reality to expectations that are strongly based in past performance (preferably of similar work in similar conditions) and being highly adaptive. This is a more adaptive, flexible environment that focuses on maximizing the value delivered rather than firm commitments to dates and scope of work.

Customers can also define it when they want performance characteristics of a service.

This is the kind of thing that does not work well in many cases. The customers can say what they desire, but that doesn't change the reality of the world. Consider the Manifesto for Agile Software Development - "customer collaboration over contract negotiation". You may need certain agreements and contracts between an organization and its service providers, but you should focus on collaborating. What is more valuable - an written agreement or evidence-based historical data and forecasts?

Daniel Vacanti wrote a very good book titled 'Actionable Agile Metrics for Predictability'. 

It goes into the difference between Service level agreement (SLA) and Service level expectation (SLE). If the task is repeatable with a high degree of accuracy then an SLA may work fine. Manufacturing facilities that leverage automation may know how many products they can product an hour with a very high degree of accuracy and tie an SLA to that. 

In knowledge work, we're solving complex problems that likely won't mirror something like manufacturing output. Using expectation takes away the 'contract negotiation' that comes with an SLA. 

Vacanti also discusses the use of Scatterplots to look at cycle times over a given date range so that the team could provide an SLE with percentages which tend to be much more useful in a conversation with a customer. Here's an example of what those SLE's could look like. This uses evidence based data that can be collected by the team over time.

1) 95% of the time a piece of work will be complete within 21 days

2) 85% of the time a piece of work will be complete within 14 days.

3) 50% of the time a piece of work will be complete within 5 days

Thanks for answering!

So, I understand what you mean and I accept what you're saying.

But the point that I’m bringing here is not only related to prediction, it is about forecasting. Sometimes we have to set up it in our contracts before starting them.

At the time we are defining how our contracts look like, there may be some scenarios that we should balance how “agile” the contracts are going to be just because in some cases is not possible to adopt the manifesto entirely.

What is more valuable - an written agreement or evidence-based historical data and forecasts?

I do agree!

I would also argue that at the time that we are dealing with “written agreement” in contracts we should do it with a reliable approach and this one should be driven by value.

I would dare to say the at the contract levels there must be agreements (SLAs), and in order to accomplish them we should work at the level of expectations (SLEs).

Let me know plz your thoughts about it.

I would dare to say the at the contract levels there must be agreements (SLAs), and in order to accomplish them we should work at the level of expectations (SLEs).

I really like what Tony Divel pointed out in his post.

There is some work that is very easy to repeat. This highly repeatable work can potentially be automated. But whether or not it is automated (in full or in part), it's easy to decompose it into a series of steps and fairly accurately assess the time it takes to complete each step and how long it will take to finish the work. If you're familiar with the Cynefin framework, this is work that is in the "simple" or "obvious" quadrant and is governed by best practices and work instructions.

But there's an entirely separate category of work. Again, in the context of Cynefin framework, it's work that is complicated or perhaps complex. The bulk of software development falls into these areas. Here, it's not always possible to have repeatable work that follows a consistent, defined process that can be estimated.

SLAs tend to be fine for the first type of work. If you apply continuous improvement techniques, you can improve the time it takes to finish certain steps or even streamline the process as a whole to get more done. But firm SLAs are often inappropriate for the second type of work. So differentiating between an SLA and an SLE is critical.

This is where customer collaboration comes into play even more. As experts in the work, you can be aware of what work can be governed by SLAs because it's highly repeatable and you can be highly confident in your ability to understand and execute according to a defined plan. However, as experts, you are also aware of what work does not fit this definition and define what you can and will do to maximize customer satisfaction and value.

I would also add that there are a lot of business considerations here.

Even if you, personally or within your organization, can understand and differentiate between and SLA and SLE, it doesn't necessarily mean that your customers or clients can or will. As experts, you can attempt to teach them the difference. If you are working with customers who are very contract-driven and are expecting a contractual commitments to a specified SLA, it becomes a game of risk management to determine if the cost of making contractual commitments to SLAs is feasible or viable for the organization.

If your organization is embracing the lean and agile values and methods, you should attempt to explain to customers and clients the advantages of working in this way, particularly for work that is not highly repeatable and how it benefits them. But, at the end of a day, a business needs clients in order to stay in business so you may not be able to just walk away from any client who isn't able or willing to collaborate fully.

Hello, it is a nice discussion! :)

Let’s check what Vacanti wrote. It is important to say that, at his book, He used SLE and SLA in an interchangeably way.

However, He made a consideration: He stated that SLA sounded like “penalties for non-conformance” and we should use the missed SLA as a way to learn, not punishing the team. That’s the only difference.

Even though agile argues that “customer collaboration over contract negotiation” contracts usually are a piece of paper that provides formality to the process. There is no product without a contract.

From the customer viewpoint a contract has to be profitable. The purpose of SLA is not itself to punish, it is used to monitor, at the contract level, how is the health of the process. The SLA can also be updated and evolved considering the evidence-based historical data and forecasts. I can’t see any problem about doing this. It only depends on the design of how the contract was constructed.

By taking a look at the “Key Learnings and Takeaways” and sections of the Vacanti’s book, I would say that we can use those recommendations as guidelines for designing the SLAs of our contracts.

Regarding to the SLAs according to the domains of Cynefin. It’s simple too. The SLAs (also SLEs) are largely different between “obvious”, “complex” and “complicated” domains.

I believe that SLA does not meant to be used only in the predictive scenarios. If you use, for instance, the “Graduated fixed-price contracts” you can have different perspectives of hours rate based of the performance of the team. In this case, both sides customer and vendor share risk regarding the schedule variance. You can have different SLA/SLE based on early (cheaper), on-time (cost already define), and late delivery (more expensive).

However, He made a consideration: He stated that SLA sounded like “penalties for non-conformance” and we should use the missed SLA as a way to learn, not punishing the team. That’s the only difference.

I'm definitely with you on this one.

I think one reason to change from SLA to SLE is because the SLA is not typically used for learning when it comes to rigid contract negotiations. If you have a customer that understands this distinction and is willing to have an open conversation when new work is discovered then it may not matter if you use SLA or SLE. 

I believe this is where a transparent product backlog can become a huge asset. As new work emerges the conversation can be made to its impact on the ability of the development team to hit the expected forecast. That creates options....cut scope, increase the time line, bring in an additional team, etc. 

I think one reason to change from SLA to SLE is because the SLA is not typically used for learning when it comes to rigid contract negotiations. If you have a customer that understands this distinction and is willing to have an open conversation when new work is discovered then it may not matter if you use SLA or SLE. 

I'm in full agreement with this.

In my experiences, SLAs are used for punishment. Contracts tend to have reporting requirements against and penalties for missing SLAs. Missing targets should be an opportunity for improvement and learning and adjustment rather than stiff penalties and punishments. By changing the terminology from SLA to SLE, you can begin to draw distinctions between these two mindsets with clients. Sometimes, changing the terminology used can be a good first step in coming to a shared understanding and agreement with less confusion. But, at the end of the day, the terminology used is less important than the shared understanding.

>>> Everyone knows that Kanban Guide comes with the SLE (Service Level Expectation) concept.

Yes. This totally explains the logic behind the change.