“Can we drop what we’re working on and focus on this URGENT thing please?”
…is a phrase all Engineering Managers and Tech Leads hate hearing.
The reflex is to say “We don’t have time / we’re too busy for that”, but it’s an antipattern.
The strong pattern looks like this: “Here’s three approaches to what you asked for: 2 hours (20% of the value), 2 days (40% of the value) and 2 weeks 80% of the value). Let’s look at what’s in this sprint and we can discuss what we should bump to make room for one of these”
Very few pieces of work require 100% of the scope to be delivered prior to the value landing. This means as a Dev, EM or TL, you should break the requests down into smaller pieces and broker a conversation about solution paths that spell out the smallest, highest value parts.
First, we need to understand the Value the requestor is chasing. Next, we need to size the goal into a few self-contained solutions.
All things going according to plan means your conversation is no longer a battle, but a simple prioritisation question: “Which of these sizes generate more value than what’s in the current sprint?”. Your stakeholder is already brimming with conviction that they are the right person to make the priority calls, so to them this feels what they were put on earth to do.
You’d be amazed how often your stakeholder either says “I’m happy with 20% @ 2 hours for now, the rest can go on the backlog” or “Now that I have better visibility on size and value, I don’t want this new piece causing slippage on our existing priorities”.
Yes, sometimes the decision will be to “Ram the 2 week version into the current sprint”, at the opportunity cost of some half-done thing going on ice for the forseeable future. We should minimise how often this happens, but I don’t think you can reliably expect to eliminate it. Sometimes that’s just what you get in startupland, but hopefully this approach at least reduces how often it’s a reality in your sprints 🤷♂️