Alright, buckle up, because we're diving into Probabilistic Forecasting. Not the most glamorous term, right? I can already sense the collective sigh. But stick with me—this math wizardry could save you, as a Delivery Lead, from the perils of estimation. It might even improve your deadline conversations! If you’re intrigued, read on. If not, I’ll catch you in another blog post.
Agile Estimation: The Usual Suspects
When it comes to Agile estimation, the usual go-tos are story points and t-shirt sizing. Combine that with the tech lead’s experience and the team's collective “gut feel” from past projects, and voilà—you’ve got yourself a deadline. Or at least, you have something that looks like one.
But what happens next? Often, the team commits to a deadline that’s a little too ambitious. As the deadline approaches, the following scenarios tend to play out:
- Scope gets cut to meet the deadline.
- The deadline is renegotiated.
- The team starts burning the midnight oil (and maybe weekends) to try and hit it.
None of these outcomes are great. Either stakeholders are upset because deadlines are missed or features are cut, or your team is stressed, cranking out code at the cost of quality, racking up tech debt along the way. Not fun.
Enter Probabilistic Forecasting
Here’s where probabilistic forecasting steps in, like a superhero wearing a very unassuming cape. I first stumbled upon this gem during an online conference in the middle of the COVID pandemic (sorry for the flashbacks). Mattia Battison was the speaker, and he completely blew my mind. Let me try to explain it in a way that won’t make you glaze over.
We’re all familiar with stories in Agile, right? You write them, you complete them, and they live in your sprints. Probabilistic forecasting uses a simple metric from your team: throughput. Throughput is just the number of stories you complete each sprint.
Now, take that number and plug it into a handy Google Sheet along with a few other inputs—like how often you run into bugs or discover new stories mid-sprint. You also need to estimate the size of your project, say 30 stories. Then, the magic happens: the Monte-Carlo Simulation.
Don’t worry, you don’t need to be a math genius. Essentially, the simulation runs thousands of scenarios to predict when you’ll deliver those 30 stories, based on your past throughput. It gives you a probability and a confidence score.
Changing the Conversation
After all that mathematical magic, you get something like this:
“We are 82% confident we can complete 30-46 stories in 3 sprints or less.”
This little sentence can be a game-changer in conversations with stakeholders. Let’s say your team misses the 3-sprint mark. The stakeholder is likely to be more understanding, because hey, you only had an 82% confidence level! And they can relax knowing the work is likely to wrap up early in the fourth sprint.
Now, let’s say they want those features in 2 sprints. You can say, “Sure, but we’re only 71% confident.” This lets everyone approach deadlines with a more realistic mindset, and your team gets some breathing room with a range (e.g., 30-46 stories) that accounts for inevitable bugs or unexpected work.
For more on this, check out Mattia Battison’s GitHub page, where he and his co-authors have shared their book, templates, and a Trello board.
What About the "What Ifs"?
I often get questions about this approach, so let me address a couple of the common "what ifs":
- What if the team’s story sizes vary?
No problem! The simulation accounts for this, because it’s based on past throughput. As long as the team stays consistent—and yes, breaking stories into smaller pieces is always a good idea—the simulations will handle the rest. - What if the work turns out to be more complex?
The simulation tries to anticipate new stories or the need to break down complex ones, which is why you get a range. But if something massive crops up, you can always update the simulation. The earlier you do this, the better the conversation with your stakeholder will go. Just don’t hold me responsible for their mood.
In my experience, this method not only improves deadline accuracy but also makes for much smoother conversations. Now, who’s ready for a (virtual) trip to Monte-Carlo?
Header Photo by Reuben Rohard on Unsplash
Inner Advice Demons & Retros: The Humble Inquiry Dilemma
Lately, in my quest to become a better agile coach, I picked up Edgar H. Schein's Humble Inquiry. The goal? To become more humble, naturally. But instead, I found myself tangled up in knots trying to understand how to stop my inner control freak from turning every question into a sneaky directive. The book offers fantastic guidance on asking genuine questions that foster understanding, rather than our typical habit of giving advice wrapped in the form of a question. You know the type—when you think you're being helpful, but you're really just telling someone what to do.
For example, you might innocently ask, “Have you tried a Kanban-style standup?” or “Have you given that team member feedback?” Harmless, right? Not quite. What you're really saying is, “Do Kanban standups!” or “Go give them feedback!” A subtle but important difference. Instead, you could rephrase with a little more curiosity: “What styles of standups have you tried?” or “How might that person take the feedback?”
Enter the Inner Advice Demon
So, there I was, mentally spiraling, wondering if I was unintentionally bossing people around instead of guiding them to their own epiphanies. Luckily, I'm part of a coaching community founded by Ben Maynard and Jon Spruce, and I turned to my peers for help. In our small group, I confessed my struggles with staying humble. The first thing I learned? It's perfectly fine to offer advice. The trick is not to be a dictator about it. Suggesting ideas is great, but don’t insist people follow your golden nuggets of wisdom, especially if it’s not working for them.
In the midst of our chat, someone shared a TED talk by Michael Bungay Stanier about taming your "inner advice monster" (or, as I call it, the Advice Demon). His point? We humans love to swoop in and solve problems, but if we slow down and ask the right questions, we can dig deeper. Sure, it takes a little more patience, but it leads to richer conversations and more tailored solutions.
Demons & Retros: A Match Made in Agile Heaven
Fast forward to my next retrospective with a small, tight-knit team. I was determined to take a new approach, something fresh that would also help me practice asking better questions. Sure, I've run the classic retros like “Stop, Start, Continue” or “Mad, Sad, Glad” more times than I can count—they work, but I needed a change.
Inspired by Stanier’s talk, I decided to try out a modified version of his questioning technique:
- What's the most challenging thing for you right now?
- What else?
- What else?
- So, now you've considered all of that, what's the most challenging thing right now?
I set up a Miro board with just the first question and asked the team to post their thoughts. Then, I followed up with two rounds of “What else?”—giving them space to dig deeper. Before asking the final question, each person walked through what they had shared so far. By the end, the team had unearthed deeper challenges than they usually would have in a standard retro.
We wrapped up by discussing actionable steps they could take to tackle these challenges. It was a refreshingly insightful session—and I didn’t even need to give them instructions (just a few gentle suggestions)!
So, why not try this approach in your next retrospective? (No pressure, of course!)
Photo by name_ gravity on Unsplash
Light bulb moment
The first time I heard the phrase "Stop Starting, Start Finishing," it was like a penny dropped in my brain. Sure, people in agile circles constantly talked about focusing and limiting work in progress, but this phrase really nailed it for me. Up until that point, my experience was more like everyone sprinting at 100 miles per hour, working on multiple things at once, and the result? Chaos.
In my previous life as a project manager in the waterfall world, this often culminated in a last-minute mad dash, fueled by late-night pizza, to push a monstrous release full of features that were often... well, let's say "not quite fit for purpose." Even after transitioning to agile, it felt like we were still spinning the same frantic plates. But when I heard "Stop Starting, Start Finishing" and gave it a try, everything changed. Now, I’m a firm believer, and I encourage teams to embrace this mantra. If you're still skeptical, check out Henrik Kniberg’s keynote (yes, the one from Spotify Engineering fame) where he illustrates this beautifully.
Kanban
Kanban is practically made for this mindset. One of its core principles is limiting work in progress. The simple act of visualizing work on a Kanban board reduces the temptation to secretly take on side projects. Or, at the very least, it encourages team members to be transparent and add new tasks to the board so everyone knows what they’re working on.
This isn’t a plug to convince you to adopt Kanban (although it is pretty great), but I find that whether you’re doing Scrum, Kanban, or some other hybrid, having a board is a super handy tool to keep the team focused.
Looking at cats on the internet (Bear with me)
You’re probably thinking I’ve lost it, right? Cats? On the internet? Have I gone mad? Well, not quite. Let me explain (I promise it’ll make sense).
So, cats. We all know they’re adorable. Exhibit A:
But here’s the deal—cats are some of the most frequently viewed images on the internet. Why does this matter? Because in the keynote I mentioned earlier, Henrik talks about building slack into the system. Slack gives your brain room to breathe, to be creative, and to work on things you’re passionate about. It’s the space where innovation happens. And in the tech world, innovation is the holy grail, but it’s nearly impossible to achieve if your team is always in "delivery mode."
Sometimes, it’s when your brain has that little bit of downtime that you experience a lightbulb moment and solve that tricky problem that’s been haunting you. So, when someone on your team asks, “What should I work on while I’m waiting for this query to run?”—instead of giving them another task, joke around and say, "Oh, just look at cats on the internet." It’ll save them from context-switching, give them a breather from the grind, and who knows—they might come back with a brilliant idea or a solution you didn’t see coming.
By focusing on finishing instead of endlessly starting new tasks, you not only reduce the chaos but also create space for innovation to thrive. So, next time, before diving into something new, ask yourself: Should I start this? Or should I finish what I’ve already begun?
Header Photo by Adam Winger on Unsplash
Cat Photo by Edgar on Unsplash
Being a Jack of all trades is often how we feel in our delivery roles, whether as a Delivery Lead, Delivery Manager or Delivery Consultant. It turns out, according to Forbes, that juggling multiple skills isn’t just a necessity—it’s a key to success!
What does "Delivery" really mean?
Delivery roles are a balancing act. There’s what the organization wants you to do, what your job description says you should be doing, and then—of course—what you actually end up doing. Spoiler alert: it varies wildly, sometimes by the day, sometimes by the hour. The magic is in adapting to whatever challenge pops up. This is where being a jack of all trades really shines—calling on a variety of skills, switching contexts like a pro, and pulling just the right tool from your well-stocked toolbox.
Personally, my career path has been a bit of a winding road. I started in a lab as a bench chemist (yes, really), then moved into project management where I was all about hitting deadlines and keeping Gantt charts tidy. Eventually, I found my way to agile delivery, which shifted my focus toward team coaching, fostering collaboration, and generally trying to keep everyone happy. Why? Because happier teams tend to be more productive. Oh, and deadlines? Yep, they’re still very real in the agile world—more on that in another blog!
So, What Does a Delivery manager do?
One of the best explanations I’ve come across for what a delivery manager actually does comes from Emily Webber's blog. She breaks it down into three key areas: lean agile practices, team health & happiness, and delivery support. Simple, right? Well, sort of. Those are just the big categories. Beneath them lies a sea of essential skills like servant leadership, communication, and facilitation.
When you look at that list, it’s easy to feel overwhelmed. So much to do, so little time. But here’s the thing: you’ve got this! (Even when imposter syndrome whispers otherwise.)
Defeating Imposter Syndrome
If you’re in delivery, you’ve probably felt imposter syndrome at some point. Maybe it’s because you’re not as “technical” as the engineers, or because you’re faced with a challenge you’ve never seen before, and suddenly feel like you’re not an expert in anything. Sound familiar?
The good news is, the agile community is incredibly supportive. There are tons of meetups—both online and in person—where you can swap stories, share struggles, and learn how others have conquered their own bouts of imposter syndrome. Networking with peers going through the same things can be super refreshing. And hey, if you ever need a chat, feel free to reach out—I’m always happy to help!
There you have it—being a jack of all trades might just be your secret weapon in the world of delivery. After all, who wouldn’t want to be versatile, adaptable, and ready for whatever challenge comes next?
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce tincidunt, leo sed tincidunt tincidunt, sapien ex mollis enim, in tincidunt quam elit vitae nisl. Sed quis bibendum tortor. Ut consequat quam non ultrices lacinia. Integer a libero sed nulla sagittis rhoncus sed vel felis. Ut sed urna luctus, finibus mi quis, rutrum odio. Donec vulputate finibus nulla, sed semper elit pharetra suscipit. Duis nec odio congue, maximus velit ac, condimentum orci. Vivamus tristique quam in augue varius, a commodo ipsum suscipit. Duis consequat mi quis eros dictum varius non facilisis nisl.
Donec ultrices mauris non finibus posuere. Proin malesuada porttitor sem nec sodales. Fusce ut nibh quam. Integer elit arcu, feugiat et sollicitudin vel, ornare eget nulla. Nunc posuere laoreet sem, sit amet tincidunt tortor congue a. Etiam et placerat ex. Nam auctor est in odio semper aliquam.
Vestibulum tortor felis, eleifend vel orci non, ullamcorper ullamcorper ligula. Nam sit amet fringilla quam. Phasellus ut pharetra mi. Morbi auctor odio vitae sem sollicitudin, non pharetra ligula eleifend. Suspendisse in arcu nec nunc elementum tempor. Suspendisse suscipit ornare elit, sit amet pretium mi accumsan ac. Aliquam sollicitudin nunc in urna maximus, egestas elementum ex semper. Nulla eget odio nulla. Nam bibendum luctus neque quis varius. Duis in porttitor ex, in fermentum massa. Phasellus orci erat, tempus in elit vel, gravida auctor neque.
Phasellus libero est, efficitur a aliquet id, tristique in est. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Integer gravida id nisi ac posuere. Duis vel dignissim velit. Nunc imperdiet ligula at ex interdum placerat. Cras porta elit erat, a vulputate elit suscipit sed. Praesent ut nisl accumsan, rhoncus felis in, varius turpis. Suspendisse ultrices ante nisl, a blandit dolor scelerisque a. Donec mauris nisi, condimentum eget tempus sit amet, porttitor ut massa. Aliquam tempor justo sed magna volutpat, eu fringilla magna ultricies. Sed tincidunt dapibus sem in viverra. Praesent tincidunt augue ut orci volutpat volutpat. Sed tincidunt, risus in vulputate iaculis, velit diam cursus felis, eu eleifend nequ