Have you ever gotten up in the morning and thought “Oh boy, I get to log-in today. It’s going to be great!” Of course, you haven’t. No user ever wants to log-in, so writing the story as “User wants to log-in” completely misses the point.

So why would we even build a log-in feature if nobody wants to do it? Because other stakeholders of the product do care about that. The key here isn’t that log-in is a bad feature, it’s that we’ve completely misunderstood who wants it and why.

When we write a user story, we should write it from the perspective of the person who cares most about it. The quickest way to find that person is to ask who would be upset if we didn’t build it, and why. In this case it isn’t the person logging in. In fact, they may actively not want this.

Write a story from the perspective of whoever cares most about it: the person who’d be upset if you didn’t build it.

Let’s improve the original story: “Corporate risk wants people to log-in before they have access to any confidential information”. Now we’ve identified who really cares and this is becoming a reasonable story. We haven’t necessarily identified that log-in is the right answer to the problem, but we’ve at least correctly identified who wants it.

Someone always brings up “but I do want to log-in so that my information is safe”, which conflates the logging in with the thing they actually do want: safety. You could certainly write a story from their perspective which focused on the safety. “User wants to know that nobody else can access their documents without permission” and that would be an improvement, although it’s still not directly linking the log-in to the safety. Does that person want to log-in or do they want to know their information is safe?

One caveat on my own wording: I’ve said “user” throughout, and that word is normally far too generic to be useful in a story. Log-in is one of the rare cases where it really does apply to everyone, so I’ll give it a pass this time.

Getting the who right is only one piece of what makes a good story; it’s part of a bigger idea I’ve written about before, that a story has to be valuable to someone who isn’t us. It’s something I often see done poorly though. The user is frequently an afterthought, when it’s critical context that helps us understand what problem we’re trying to solve. If we don’t know who we’re building it for, we’re almost certainly building the wrong thing.

They think the meeting is the improvement. It isn’t. The meeting is where you decide what to change. The improvement doesn’t happen until you actually change it.

Most teams I meet are running retrospectives because they’re on the calendar, and nobody questions what’s on the calendar.

They brainstorm, group the stickies, vote, write down the actions, close. Then next time, the actions from last time are still sitting there undone, so they brainstorm the same problems again. No wonder they get frustrated, all we’re doing is rehashing the past.

A couple of times I’ve walked into a retrospective where the team hadn’t done any of the actions from the last one. I asked whether those actions still mattered, and when they said yes, I stopped the meeting. “Then go do them now; this meeting is over.”

The room then goes quiet, and people look at each other, waiting for the catch. Nobody ends a meeting halfway through. You run out the time whether or not there’s anything left to do. So sending everyone back to their desks with time on the clock breaks a rule they didn’t know they were following. Go do the thing you already agreed to do, because the retrospective was never the point. The change was, and the change isn’t done yet.

The retrospective is one of the most important meetings your team has. Run it without improving, and you’ve wasted everyone’s time.

If you want to run retrospectives that actually change things, that’s what my course Retrospective Magic is about.

Every once in a while, though, I come across a team that’s added a second one. They have a Done, and next to it a Done-Done. The story is always the same: Done stopped meaning done. Work would land in that column and then come back, so the team needed a new column to hold the work that was really, actually finished this time.

That extra column is the feedback we should be looking for. Language doesn’t rot on its own; it rots because we aren’t willing to have the hard conversation about what the word means.

Underneath this particular word, the conversation we’re avoiding is almost always about silos. Someone finishes their part and moves the ticket to Done, because from where they sit, it is done. Their part is done, but the overall work isn’t. It’s done when everyone has done their part. Developer-done isn’t done. Tested-done isn’t done. Each group has its own private definition, anchored to the edge of its own silo.

So instead of getting in a room and agreeing on one shared definition that spans all of those silos, the team bolts on another column. The columns are the silos. Done is where development hands off. Done-Done is where the next group hands off. Every qualifier we add is a handoff we didn’t want to talk about.

Once you see this, you see it everywhere a qualifier starts multiplying. Done-done. Final-final. The real deadline, as opposed to the one we told everyone. A word that needs reinforcing is a word people have stopped trusting, and a multiplying qualifier is a conversation nobody wanted to have.

I had a client once that had a Done, a Done-Done, and a Done-Done-Done. And even Done-Done-Done didn’t mean it was in production. It’s time to stop doing that.

Let’s start with the obvious case. A WIP limit is part of a policy that the team agreed to. The policy says what the team will do, and here it says the WIP in a column will not exceed a certain value. So if the WIP goes over that value, then yes, that’s bad. We agreed to a policy and then didn’t follow it. Simple.

Except that original question was asked in the context of working in Jira, and that shifts the focus.

What Jira actually measures

Jira only supports column-based WIP limits. That means what Jira enforces might not capture the subtleties of what your policy actually says.

Imagine your policy reads: the WIP limit for this column is 5, unless an item in the column is expedited, in which case the limit rises to 6. That’s a perfectly reasonable policy, and Jira can’t express it. All Jira knows is the number 5. So the moment that expedited sixth item appears, Jira flags you as over the limit, even though you’re following your policy exactly.

In a case like that, the fact that Jira thinks you’re over doesn’t mean you violated anything.

So is breaching WIP bad?

It depends on what the breach actually represents.

If your WIP measurement accurately reflects the policy you agreed to, then yes, breaching it is bad. You said you’d work one way and then you didn’t.

If your WIP measurement is wrong because your tooling can’t express the policy, then the breach is an artifact of the tool, not a failure of the team.

The lesson isn’t that WIP limits don’t matter. It’s that the number on the board and the policy in your head aren’t always the same thing. Before you treat a breach as a problem, check which one you’re actually looking at.

If you’d like help making better decisions from your team’s metrics then let’s talk. I’m available to help.

The senior couldn’t stop talking about how much he had learned from the junior, in that short time working together. He stressed that together they came up with a much better solution than either one of them could have done on their own.

While this is extreme example, this kind of result when we truly collaborate is typical. Together we come up with much better results than when we work independently, no matter the skill levels of the people involved.

So why don’t we collaborate more? I think there are several reasons.

1. Most people have never experienced real collaboration and they’re convinced that what they already know is as good as it gets. It’s not.

What most teams call collaboration is actually coordination. You divide the work up, each person goes off and does their piece, and then you review each other’s output. That’s not collaboration. Collaboration is working on the same problem together, at the same time, building on each other’s thinking in real time. It’s uncomfortable at first, especially if you’ve spent your career with your own task list and your own sense of ownership. But what I’ve seen again and again is that the discomfort fades quickly once people experience what’s actually possible.

2. We’ve been trained from childhood that individual accomplishment is the only valid way. All the way through school, it’s called cheating when you share your answers with others. And having been trained that way, it now feels uncomfortable to actually collaborate.

We spend 12 to 20 years having that framing reinforced, and by the time we enter the workforce it’s deeply embedded. Most corporate performance management systems reinforce it further: your review is about your contributions, not your team’s contributions. Even when the work itself calls for collaboration, the incentive structure is still measuring individuals. That tension doesn’t disappear just because you’ve decided to work together.

3. There is a shared psychological bias that believes that two people working together will take twice as long to get the work done as those same two people working independently. This is despite decades of research on pair programming that shows the opposite. The bottleneck has never been typing speed, it’s always been thinking speed and we think better when we collaborate.

The math seems obvious: two developers, one task, surely you’re cutting your throughput in half. But it’s wrong, because it ignores where the actual time goes. Laurie Williams’ research at the University of Utah in the late 1990s and the studies that followed consistently showed that pairs take roughly 15% longer to produce code, but that code has significantly fewer defects and requires less rework. When you factor in the bugs you don’t ship and the rearchitecting you don’t have to do six months from now, the economics look very different. The cost you’re seeing is real. The savings are invisible because they’re in futures that never happened.

So here’s my challenge to you: before you decide collaboration isn’t worth it, actually try it. Not someday. This week. Pick one piece of work and do it together: same screen, same problem, both people present and contributing. Not dividing it up, not reviewing each other’s output. Actually working on it simultaneously.

Then pay attention to what happens. Notice what comes up that wouldn’t have come up if you’d been working alone. Notice where the other person catches something you missed, or takes the idea somewhere you wouldn’t have gone. The experience itself is the evidence.

If you’re not sure how to get started with real collaboration, or you’ve tried it and it hasn’t clicked, let’s talk.

See also:

• Pairing
• Ensemble/Mob programming

Someone asked the question that almost always comes up: was development (coding, thinking, verifying your own work) ever really the bottleneck?

My answer is yes, and the evidence is the fact that we’ve been staffing up on developers for decades to address the bottleneck. Why else would we have seven developers in a team of ten people, if that piece wasn’t slow?

AI tools have made developers much faster at writing code and moderately faster at the rest, and yet on many teams, value isn’t reaching customers any faster. On some, it’s gotten objectively worse.

Eliyahu Goldratt, in his 1984 book The Goal, introduced the Theory of Constraints. Every system has a single active constraint — the bottleneck that limits overall throughput. Speeding up any other part of the system doesn’t improve output; it just builds up inventory in front of the constraint. And when you do speed up the bottleneck, the constraint moves somewhere else.

Most development teams have more developers than testers, and more testers than product people. That staffing shape has traditionally been because of where the bottleneck was, and now AI has shifted it to where the team is thin.

Some teams had already built amazing quality into their products, and had automated away most of the need for manual testing, but for those who hadn’t, testing has now become a significant bottleneck. We’re flying through the coding stage and are piling up in testing. This is the bottleneck shifting right, or closer to completion.

Many teams are letting the AI write all the code and are still doing fully manual PR review, which causes another significant bottleneck. Nobody can meaningfully review hundreds of changed files under time pressure.

The bottleneck also shifts left, back towards product decisions. Most teams have always had a significant number of items in their backlog, from which we pulled a little at a time. Since it took so long for the actual development, we were forced to prioritize which of those items from the backlog would get worked on. What’s happening now? Since we’ve sped things up so much, many teams are pulling things from the backlog that never should have been implemented. Things that had been accumulating but that never would have been built in the old days. Now we have the capacity to do them all, and aren’t stopping to think if we should.

Building the wrong thing fast doesn’t help anyone.

The answer isn’t to thin the developer ranks; it’s to grow the capacity everywhere else. We should be doing more with the same people, not the same with fewer. The goal is a team where the bottleneck keeps moving because we’re growing capacity across the whole team.

If development wasn’t your bottleneck to begin with, then you’ll see different shifts, but the concept is the same. AI doesn’t guarantee that you’ll deliver more value to your customers, faster. It just shifts the bottleneck to where the team is thinner, and now you have a different problem to solve.

Your bottleneck has moved. Do you know where it is now?

See also:

• AI and Critical Thinking
• Growth vs Fixed mindsets and the influence of AI
• Flowing value

⮕ Building it right: Do we have strong technical practices? Are we able to quickly and reliably get features built that will then run with high quality in production? If we can’t make a change without breaking something else we’re not winning.

⮕ Building the right thing: Building the wrong thing fast, helps nobody. Are we actually building the right thing at the right time? Are we validating that what we built did meet the clients needs?

⮕ Building it sustainably: Are we able to maintain the current pace indefinitely or are we burning our people out? Are we balancing out long term need against short term need to avoid taking too many shortcuts?

All too often we focus on just one or two of these. The hype around AI is a perfect example. Yes, it makes us able to write code significantly faster, but are we building the right things and doing it in a way that we can sustain? Are we building a foundation that we can keep working with, or are we making a lot of short term decisions that are going to come back and make our lives miserable later?

In some cases, I see teams that are successfully achieving all three with the use of AI and getting amazing results. In others, I see them deliver the wrong things faster than ever before, and in ways that will come back to haunt them.

It’s worth asking: are we keeping an eye on the bigger picture or are we hyper-focused on the shiny new toy?

See also: Why people don’t use Monte Carlo from a few weeks ago.

1. Only talk about things that are finished. If it’s half done, it’s not ready for a demo.

2. Ony talk about the value delivered, not how you got here. The audience doesn’t care that you were busy. They care about the things that they can now do that they couldn’t do before. They care about things that used to annoy them and don’t anymore.

If you’re an amazing storyteller then you can probably break both these rules and still have a riveting demo. Most people can’t do that. Stick to these two points and your demo will improve right away.

The first question I always get is “what if we don’t have anything that’s finished or anything that’s valuable?” Cancel the demo. You aren’t ready, and you’d just be wasting everyone’s time.

If you want a third tip, it’s this…

3. Show actual working product, not a slideshow. Nobody wants to see a slideshow.

This leaves us with a hole in the ground, in the shape of a tree. Tunnels where the roots used to be but with no obvious reason to be present. If you hadn’t known that a fire had come through, you wouldn’t understand why this hole was there or what the tunnels were for.

This particular picture was taken a year after a forest fire had raged through the Kelowna area, where I live. All that’s left is the hole, although you can see that nature is returning and that some flowers are now growing where the tree used to be.

Organizations leave the same kind of imprints. When a process, a system, or a person is removed, the shape of what was there often remains as review steps that nobody questions, signoffs that slow everything down, and manual steps that everyone agrees are unnecessary but nobody is willing to automate.

The most common cause I’ve seen is some kind of production outage. Something goes wrong, people panic, and a gate gets added. A mandatory sign-off. A required review. A checklist before deployment. These gates are designed to prevent that specific thing from ever happening again, and in the immediate aftermath they make good emotional sense (although often not logical sense).

The problem is that they’re rarely revisited. The incident fades from memory, the people involved move on, and the gate remains, and nobody remembers why.

Sometimes the gate was never really about the risk at all. It was about a specific person who got burned, or who got yelled at by their boss. The process existed, in part, to protect them. When they leave, the emotional logic of the process leaves with them but the hole remains.

I was once in a meeting of senior people at a bank, discussing whether physical signatures on paper forms could be replaced with electronic ones. The legal team had already weighed in: electronic signatures provided just as much legal protection as the physical ones, and yet nobody in the organization was willing to sign off on dropping the physical signature requirement. There was too much personal risk for the person who would make that decision.

If you remove the requirement and nothing goes wrong, nobody notices. However, if you remove it and something goes wrong, you are now the person who removed the safeguard. The fact that the safeguard wasn’t actually providing any protection is irrelevant to your career. So the rational move for each individual person is to leave it in place; even when everyone in the room agrees it serves no purpose.

This is how imprints persist.

If you’re experiencing unexplained friction in your organization, steps that feel like they shouldn’t be there, approvals that nobody can justify, processes that seem to exist for their own sake, it’s worth asking what used to be there. There’s usually a hole in the ground. Sometimes there’s a tree still smoldering. And occasionally, if you look carefully enough, you can find someone who remembers the fire.

If you’re in a position to remove these imprints, the good news is that in my experience it rarely backfires. The processes are usually not doing what people think they’re doing. The harder problem is getting anyone to accept the personal risk of being the one who removed the safeguard. That often requires someone with enough organizational authority to absorb the risk, or enough credibility to make the argument that the risk was never real to begin with.

The flowers in that photograph are growing where the tree used to be. Nature isn’t sentimental about the hole, and we shouldn’t be either.

We didn’t know how long we’d have before the approval arrived so we started with a bit of training on technical practices and then started working all together (ensemble work) on reviewing and improving their existing code. We refactored the code to make it cleaner and more maintainable, and improved the automated testing. We optimized their build pipeline and got them ready for continuous delivery (CD), something they hadn’t previously considered.

When the legal approval came along a few weeks later, this codebase was already in far better shape than when we’d arrived. The code was cleaner, there were fewer bugs, and all the team members had a better shared understanding of everything.

Additionally, this new service was released on a working CD pipeline, releasing to production on every commit.

How was this all possible? The most significant reason is that for the first time, they had no delivery pressure. Nothing was splitting their attention twenty different ways. Nobody was insisting that they work on multiple things at once, or watching to make sure they were busy.

Their only goal was improving what they already had. They had time to focus on the quality of the code. They had time to optimize their pipeline. They had time to learn new skills that they didn’t already have.

And then they delivered something amazing.

The most frequent objection that I get to new improvement activities is “delivery pressure”. We’re too busy to do that now. The problem, of course, is that no matter what we might tell ourselves, that pressure is never going away. We won’t have time to improve unless we make time.

If we don’t improve then we’ll continue to deliver at the same rate that we were delivering before. If we do improve, we’re likely to deliver much faster than that. There is a cost to not improving, and it’s one we often disregard.

If that team at the beginning hadn’t taken a few weeks to fix their system then they’d still be responding to quality issues the way they always had. They’d still be manually deploying the way they always had. They’d be just as busy, and as ineffective as they always had been.

They were lucky. A legal complication had given them an amazing opportunity to improve and they did. Other teams aren’t as fortunate and don’t have that slack time handed to them.

If we want to improve, we have to make the time for that, regardless of how much delivery pressure we might feel.

See also:

• Tom DeMarco’s classic book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
• Playing the long game

Are you really going to look at fifty of those on a regular basis? You might for the first few days or even weeks, and then you won’t anymore.

I had an executive once ask me to email a freshly generated 250 page report every hour through the day to his cell phone, so he could keep an eye on things. It took far too long to convince him that this was not a good use of anyone’s time and that in any case, it was giving him entirely the wrong level of detail.

At the opposite end, I had one client that had automated six key metrics to be sent to all senior leaders every 45 minutes. Six simple numbers from which they could tell at a glance if everything was running smoothly or if they needed to refocus their attention.

Another client had a large wall of metrics and analytics on monitors beside the exit. Anyone leaving the building could see at a glance if everything was ok or if there was something needing their attention before they left.

These are all examples of realtime, or near realtime, metrics but not everything has to be that fast. If we’re looking at the speed at which a software development team is completing features, looking at metrics even once a week might be too often.

If we’re looking at value delivery and whether we built the right things for our customers, even quarterly might be too often.

So we need to consider not only what we’re measuring but also how frequently we review that data.

At a high level, there are three main groupings of metrics that I normally want to start with.

Flow metrics tell us if the work is moving through the system. I usually start here, partially because they’re the easiest to measure, and partially because they will uncover a huge number of the problems with little effort. If the work isn’t getting done then really nothing else matters.

Value metrics tell us if we’re spending our money wisely. Are we doing the right work? Are we doing it at the right time? Is it of the right quality?

Sustainability metrics tell us if we can continue at this rate indefinitely or if we’re just running towards a cliff and going to crash.

I tend to look at flow metrics regularly as they give me immediate feedback on the health of the system. Value and sustainability tend to be longer term views into the system. They take longer to collect and are reviewed less often.

What do I almost never care about? How busy we are. Busyness is not a proxy for either effectiveness or efficiency, and I’ve written about that before so I’ll leave it today.

So I start with “is the work moving well?”, followed by “is the right work?”, and finally “is what we’re doing sustainable?”

For each of these, I want to find a small set of metrics that give me a glimpse into the system. I don’t want too many different measurements as that becomes overwhelming and I don’t want to have too few because then they’re easily gamed.

Not sure what you should be measuring in your environment? Let’s talk.

The four flow metrics that we typically start with are Throughput, Cycle Time, WIP, and Work Item Aging, and all of them are measured relative to the start and stop points. Without clarity on those two points, none of the metrics will be helpful.

So where do we really want to measure those?

At a high level, there are two parts to the start point (Ready). Someone representing the business has agreed to spend money on this work, and the team understands what they’re being asked to do. It’s worth noting that the team does not need to understand how they’re going to do the work yet. Figuring out the how is part of doing the work and happens after the clock has started.

Our stop point is similarly simple, we aren’t coming back to this work. What does that mean? If it hasn’t been tested yet then it’s highly likely that we are coming back to it because we don’t know if it works yet. We stop the clock when we have a reasonable expectation that we are not coming back to this work.

Each team will likely have more specifics that they want to capture, to provide a checklist of the things required for each of those two points. Perhaps the code must be checked in, reviewed, and merged before we can say we’re doing. All of this is towards satisfying the high level point of we aren’t coming back to this.

A common mistake made with both of these points is that individuals think that the points are measuring them personally, when in fact the measurements are about the work. We don’t care that a developer finished coding, the work isn’t done until other people have done their work as well.

This also holds true for the start point. I’ve seen lots of teams count the work as started when a developer starts coding, yet the work usually started well before that. Has the team not already had discussions about this work during a refinement/planning meeting? The moment we committed to doing the work is when it started, not the time we touched some code.

Many people want to defer the start point as long as possible to make the numbers look good. What we really want to do is make the reality visible so that we can start improving it. If we held a refinement meeting a month ago and brought the work to ready at that time, then the work has been started for a month, whether or not a developer has touched it since.

We don’t like that because it makes the numbers look bad, but instead we should be happy that we’ve just identified problems in the workflow. Why did we refine the work so early? All we did is build up an inventory of tickets that we aren’t working on, and inventory is one of the classic wastes in Lean.

If the work has been fully refined, the clock should have started. If we’re not coming back to it, the clock should have stopped.

Always remember that we’re not collecting metrics for the sake of being busy. We’re doing it in order to make better data-informed decisions. Better decisions require a better understanding of the system, and that needs accurate measurements.

See also:

• If you’re trying to get flow metrics out of Jira, take a look at my own JiraMetrics.
• If you just want to learn more about these four metrics then check out my online course Flow Metrics Basics for Agile Teams

Frequently when I talk about that, everyone nods their heads and then immediately makes a target out of the measures they’re looking at. It’s harder than it sounds, to get this one right.

Let’s look at an example. Let’s say that’s we’ve decided we want better code coverage for our tests. We want the confidence of being able to make a change to the code and knowing that if we made a mistake, the tests will catch that. Having a safety net like that, has huge value to the organization.

So we might measure code coverage as a percentage. How much of the production code is executed during a test run?

That’s a reasonable measure, that we can then use to make some decisions. Not as many good decisions as people normally assume, but still a good measure.

The gotcha is that many people will then immediately turn it into a target. If we’re currently at 60% coverage then someone might decide that we need to increase that to 80%.

As a measure, it was great. As a target, it’s horrible as it now encourages people to add tests that increase the test coverage numbers, whether or not those tests improve the original goal of having a better safety net.

You might be thinking “nobody would game those numbers in my organization”. They will and they do. Code coverage in particular, is gamed everywhere.

Lou Gertsner, former CEO of IBM, has famously said: “People don’t do what you expect, they do what you inspect.”

What might it look like if instead of making code coverage a target, we’d left it as a measure?

We might have hypothesized that if we adopted Test-Driven Development, that might improve our safety net. So we could try that for a period of time and then looked at code coverage as an indicator of whether we were improving or not. Not a target, but an indication of the direction that we were moving in.

Side note: I want to point out that while it’s phrased as being Scrum specific, this is equally applicable to a kanban team.

My immediate answer was yes, but it requires some context to understand why.

The daily scrum is without a doubt, the simplest of all the scrum meetings, and yet it’s one that’s frequently done very poorly. The question was specifically about a “mature” scrum team though, so let’s assume that they know how to do this meeting well.

What would this meeting look like if it didn’t need facilitation?

People would show up at the appointed time, they’d look at the board and decide which was the most important item. Then someone who knew about that item would talk about it and when they were finished, the team would move on to the next most important item and talk about that. When all the items had been discussed, the meeting would disperse. Nobody would have needed to be prompted. Nobody would have needed to be reminded to share the screen. Nobody would have talked too long, or drifted off topic. Any one of those things would have required facilitation to get back on track, and we’re talking about the case where a facilitator isn’t needed.

Is this nirvana even possible? Sure, I’ve seen teams do this for a couple of days, where they stay really focused and keep each other accountable. Then they get tired or distracted and start to let things slide. The key is that although it’s possible for a short time, it doesn’t last.

That’s why we need facilitation. There needs to be someone, or a couple of someones, to keep everyone on track, to move things along when they start to stall.

Does this imply that we need someone with the title of facilitator? No. When there is no designated leader, a natural leader will emerge from the group, and that person will either start facilitating themselves or will ask someone else to do it. This is normal team dynamics.

Interestingly, even when there is a designated leader, a natural leader will often emerge anyway, and sometimes that person does a better job than the person with the official title.

So back to “does a mature team need a facilitator?”, yes, although that person doesn’t have to have the title of facilitator. If we don’t have any facilitation at all, the meeting will very quickly lose any effectiveness that it once had.

A related question is “does it always have to be the same facilitator?” and that’s a resounding no. In fact, I recommend rotating facilitators, at least for the daily scrum, through all of that meetings participants. It’s been my experience that when everyone has a turn being that facilitator, the team takes the entire meeting far more seriously, and consequently does a much better job of it.

Let’s start by defining those two terms:

• A deterministic answer is precise: “It will rain at 3:05pm today.”
• A probabilistic answer contains some imprecision, despite being more correct: “There is a 80% chance of rain after 3:00pm today.”

Or in the case of the typical projects we’re working on:

• Deterministic answer: “We’ll be done on March 1.”
• Probabilistic answer: “There is an 85% chance that we’ll be done on or before March 1.”

The deterministic answer is far more satisfying to our brains, despite being both less accurate and often misleading. Our brains are optimized for energy conservation and want to use as little energy as possible for any decision. The precision of the deterministic answer is attractive as we can just use that without doing any processing of the answer.

Our brains have many shortcuts built-in to optimize for that energy usage, and these are generically called cognitive biases. We tend to lean on these even when we’re in a calm state and then when we’re under pressure, or feeling unsafe, we use them even more.

Precision Bias is when we believe that something more precise is automatically more accurate than the less precise answer. Stating that we will deliver on March 1 appears more reliable. It feels like a better answer, even when objectively, it’s not.

An 85% chance of meeting a date means that there’s a 15% chance that you won’t. The cognitive bias of Loss Aversion tells us that we’re more likely to weigh potential losses more heavily than equivalent gains, leading to biased decisions. We want certainty and even a 15% chance of failing will be given disproportionate focus. A deterministic answer does not trigger loss aversion.

Probabilistic forecasts make variability visible, and Illusion of Control wants us to pretend that we are in full control. In an environment of low psychological safety, an uncertain answer can be interpreted as weakness and therefore dangerous.

An interesting variation on Illusion of Control is that many managers would prefer to have a deterministic answer that they KNOW is wrong because feel that they still have control over that. “I know they won’t make the first scheduled date, but they might make the second.”

Probabilistic forecasts are inputs to decision-making, not decisions themselves. When leaders expect a single “right answer”, probabilistic data can feel like a refusal to decide, and that can backfire on the person providing the forecast. It’s often safer to provide a deterministic answer that’s wrong.

So am I suggesting that you should give up on probabilistic forecasting and provide deterministic answers instead? Not at all.

What I’m suggesting is that we should understand what’s getting in the way of us making effective decisions from accurate data. If we don’t understand our own biases, then they will continue to control us. In this case, not understanding will lead to poorer decisions.

We should also strive to increase safety across our organizations, for many reasons, but in this particular case so that we can make better decisions.

In the chart below, we can see the total WIP per day grouped by whether it’s active (blue), stalled (light orange) or blocked (darker orange).

Stalled in this chart means that there has been no activity on the ticket in five days. No comments, no status changes, no subtasks moving. Most likely we haven’t had the time to work on these because we’ve been so busy with the few items in blue.

Blocked means that we can’t work on this because of some external dependency. Perhaps we’re waiting for a signoff, or an environment to become ready.

What we can see with this team is that with a WIP of roughly 15, only a few items are actually being worked on, on any given day, and this is typical in my experience. The higher the WIP is in total, the more of those items are stalled, or blocked.

The team I mentioned last week, with 227 items in progress, was adding value to almost none of those tickets. Almost everything was stalled.

The bottom line is that total WIP only tells us a part of the story. It tells us what’s started but not what’s actually being worked on at any time.

When the WIP is low, we can be fairly confident that all the started items are actually moving along. When the WIP is high, it only tells us that we’re busy, and little else.

Busy is not the same as effective. In fact, busyness and effectiveness are often inversely related. As we become better at one, we become worse at the other.

Starting work items that then just become stalled because we don’t have time to work on them, is not an improvement. That just creates waste and decreases our effectiveness.

Chart from JiraMetrics

It depends on the composition of the team, both size and skills, as well as the nature of the work that flows through the team. It depends on dependencies we might reasonably expect.

It also depends on the larger system that the team resides within, although that’s a much larger topic than I want to address right now. That gets into Systems Thinking or Theory of Constraints, and we’ll discuss them another time.

What do we know about work in progress for a single team?

We know that as a general rule, lower WIP across the team will result in work getting done faster and with higher quality, compared to higher WIP across that same team.

We know that there are very rare exceptions to this where WIP that’s too low can actually make things worse. Many teams are afraid that by lowering WIP, they’ll be affected by this, and so they’re reluctant to lower that WIP. Let me assure you that your team almost certainly won’t have that problem. Not for a long time, anyway

We know that it’s possible, despite what many people think, to consistently have a WIP of 1 or 2 across the entire team (see ensemble / mob programming, and those teams tend to be exceptionally effective.

We know that having a WIP that is measured in multiples of the number of people, is almost always a disaster (ie 20 items in progress for a team of 5). The worst I’ve seen was a team of 10 people with 227 items in progress. They spent all day either context switching or arguing over what was important. Nothing got done.

We know that having a WIP that’s too high will invalidate most of the business prioritization that you’re doing.

So what should the WIP be for your team? If you’re asking the question then almost certainly, lower than what it is now. Lower it and see what results you get.

Then lower it again. And again.

See also: the “lowering the water level” metaphor from Toyota.

Looking back, I’m sure we’re all horrified at how inefficient this was. For the price of a few more version control licenses, we could have eliminated a significant amount of process waste. The one gatekeeper would have been able to do much more of his own work, and nobody would be sitting around waiting for that person to finish.

Yet, we see similar patterns with workflow systems (ie Jira) today. Although everyone might have a license, it’s common for only one person to ever update the tickets. During our daily meeting, people will provide updates and one person will then laboriously type them into the system. Just like with that version control, we’ve chosen to have one person be the bottleneck.

Even worse, when it’s all down to one person, they often feel pressured to add some comment like “still in progress”, even when it doesn’t add any value. So not only are we slower, but we’ve added all kinds of noise to the tickets.

Consider how much more efficient we’d be if everyone updated their own tickets and had done so before the meeting even started. Then we could spend our time together talking about the things that actually need our attention, rather than watching one person type, or drag tickets around.

A class of service reflects the fact that we behave differently for each. That we give more focus and attention to a high priority item than we do to a lower priority item.

The five Jira priorities that we get out of the box are:

1. Highest
2. High
3. Medium (the default)
4. Low
5. Lowest

Let’s assume that we use all five because realistically, if the option is there then people will use it.

It’s reasonable to assume that most items will be the default (Medium) and will stay there. Given that, what’s the likelihood that we’ll ever do Low or Lowest priority items? If we’re honest with ourselves, it’s unlikely that we’ll ever run out of Medium items so the Low and Lowest items should starve for attention.

That begs the question of why we ever allowed a Low or Lowest priority items to even move onto the board in the first place. Why would we ever start it, if we know we’ll never give it any attention? Clearly we shouldn’t so those two are redundant and could be safely removed.

Yet, when we look at data from actual teams, we see that Low and Lowest items do get started, even when they haven’t run out of Medium items. What does that tell us about how we use priorities? It means we largely ignore them; we treat them as hints, not rules.

In fact, if we graph cycletimes across priorities, we see that the more priorities are in use, the less difference they seem to make. When we only have two priorities, we can clearly see that the higher priority items get done faster than the lower priority ones. When we have five, it’s very difficult to see any correlation between priority and time to complete.

So what do I recommend instead? Have only two priorities: standard and expedited. If it’s a standard priority then treat all work first-in, first-out. Older items are more important than younger items. If it’s expedited then it’s more important than any standard item so do that first. If you have multiple expedited items then do them in first-in, first-out order as well.

Having only two levels reduces all the complexity, while still giving us a way to boost an item that needs it. The vast majority of items should be normal priority.

Of course, even having two priorities doesn’t solve all the problems. We’ll still have situations where what we say doesn’t match our actions. If an item is expedited then we should be jumping on it and doing it first, yet we routinely see things marked as expedited and then everyone working on other non-expedited work instead.

That’s like an ambulance on the highway putting its lights and sirens on and then stopping to let other people pass it. Behaviours need to match labels; if the lights are on, it should be moving before anyone else. If we mark an item as expedited, we need to do it before anything else.