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.