This version updates an original article from June 7, 2021. With the latest thoughts on Service Level Expectations, it's been refined for clarity and relevance as of March 16, 2024.
In the dynamic realm of project management and team productivity, traditional metrics like Delivery on Commit (DoC) often fall short in capturing the essence of team efficiency and adaptability. While DoC, or the Say/Do ratio, has its merits in instilling discipline within teams struggling to meet deadlines, it barely scratches the surface of what makes a team truly efficient. It's time we pivot our focus from merely fulfilling commitments to understanding and optimizing our Service Level Expectations (SLEs).
Why Move Away from Delivery on Commit?
DoC metrics encourage a "feature factory" mindset—prioritizing delivery over value and adaptability. This approach, while it ensures tasks are completed, often overlooks the importance of sustainable pace and the ability to respond to changing demands. Instead of asking, "Did we deliver on time?" we should be asking, "How can we deliver efficiently and adaptively?"
Unveiling Service Level Expectations
SLEs offer a more nuanced and flexible approach to measuring team performance. By analyzing the cycle times of past projects, teams can set realistic expectations for delivery times at different confidence levels. This method not only provides a clearer picture of team efficiency but also encourages continuous improvement.
How to Calculate Your Team's SLEs
Gather Data: Start with the last six months of team story data. Adjust the timeframe based on your team's consistency or duration of formation.
Calculate Cycle Times: Ensure each work item has a calculated cycle time. This will be crucial for understanding your delivery capabilities.
Determine Percentiles: Calculate percentiles for your cycle times—50%, 75%, 85%, 95%, and 99% are good starting points. Each percentile offers insights into your team's delivery reliability and potential areas for improvement.
From Data to Action
With SLEs calculated, it's time to strategize for better efficiency. Implementing Work in Progress (WIP) limits, focusing on work item age during standups, and adopting a more collaborative approach to tackling aged items can significantly reduce cycle times.
The Path to High Performance
Achieving a steady, sustainable flow of work requires continuous attention to the work process. Techniques such as breaking down stories, pairing, and focusing on one-piece flow can further enhance team predictability and efficiency.
Believe in Your Team's Potential
Transforming your team into a high-performing unit is not a distant dream—it's a tangible goal. By shifting focus from rigid delivery metrics to flexible, insightful SLEs, you pave the way for not just meeting expectations but exceeding them.
Below is the original article, first published on June 7, 2021. It lays the groundwork for the concepts discussed in the updated version above.
https://agile-ideation.com/blog/2021/5/16/forget-delivery-on-commit-whats-your-service-level-expectation
Forget Delivery on Commit - what's your Service Level Expectation?
I’ve been pretty vocal about how little I like Delivery on Commit (also known as Say/Do) measurements - sure they have their place and can be useful like if your team is struggling with general discipline and doesn’t seem to get much work done (at least compared to how much they start) and you’re working in a sprint or iteration based environment then DoC can be a practical place to start.
However once your team starts getting a better sense of what’s a sustainable pace for them and how much they can deliver, we really want to de-emphasize DoC or else we risk turning into a feature factory - “Deliver what you say no matter what happens!” - that’s the anti-pattern that I see most people fall into with DoC and why I don’t like it.
So instead let’s take a look at your current service level expectation!
I do this using an Alteryx workflow, but there are lots of ways you can calculate this. We’ll talk through the steps and you can try doing it yourself.
Go pull the last 6 months worth of team story data. Maybe less if the team has been more consistent lately. And if your team is pretty new, you can use as much as you have available.
Make sure you have cycle time for each item - you might need to calculate this and add it to your data set
calculate your percentiles on your cycle time in days - at most I’d suggest 50%, 75%, 85%, 95%, and 99%.
my standards are
50% will basically be a coin flip - half your items are below this point, half above - I generally consider
85% is a generally accepted “high confidence” point in general stats
I use 95% and 99% just to get a sense of the total picture and spread to a very high level of confidence. It’s possible in some cases 85% is not confident enough and we want to be more conservative
but sometimes I do use
25% can sometimes be an eyeopener for teams - there’s only a 1 in 4 chance of you getting it done within 10 days - suddenly it’s obvious they miss completing in an iteration 3 out of 4 times and maybe we should do something
75% might be useful if you’re wanting a slightly less conservative estimate than the 85% - 3 out of 4 is not bad for a lot of people, and seeing the range for 75% to 85% can also give you a sense of some spread on the reliability
Now we have a set of expectations around when we can be expected to deliver for any random story at any particular level of confidence. We can also use this to help us focus on the work and moving it through so we have continuous flow.
Using the sample data above our 85% cycle time is 16 days that means it takes us more than an entire 2 week sprint to get any random work item done.
First let’s try to get down to completing within a sprint - that’s 10 working days or 14 calendar days (we should be calculating cycle time in calendar days!). We can work on hitting our target by starting less work so we focus on seeing things through to the finish line when we start them - we can do this by implementing a WIP limit. We can also focus more on work item age, so in our daily standup instead of going around person by person let’s walk our Kanban board and look at each work item - we can even start with the longest aged items first.
Eventually let’s start setting a check-point where we might swarm on something - if our target is 10 days maybe any item that ages to 7 days needs to be prioritized and swarmed by the team for completion. We make each of these changes slowly and once we start getting closer to our targets - maybe eventually we get to 85% done in 5 days just by focusing on the work and managing it through the system.
At a certain point we’ll max our just by focusing on the work already in the system and we may need to try other things - making stories smaller, or pairing or working as an ensemble (previously known as a mob), focusing on one piece flow - until we reach the point where we’re just moving work through at a consistent, steady, maintainable, sustainable rate of flow. In this world we’re highly predictable, effective, efficient, and working like a true high performing collaborative team. Can you do it? I believe in you, we just have to try.