When a team has your change deep in their backlog

You need to make an important change to a software. Or in general – you need to modify something in a company. Unfortunately, the change depends on more than one team (department, person). You depend on others. And the team has your change deep in their backlog. It’s not a priority for them. They have planned your change for the distant future or not at all yet! Sounds familiar? We’ve got a problem.

What’s the problem?

You see the priority of the change very differently. You need it right away. The others don’t agree. They have other tasks to be finished earlier. How to deal with this? Let’s take a closer look to the root causes.

Problem root causes

You haven’t checked dependencies

Did you know that there is a dependency on another team at all? Have you realized that you cannot deliver something without someone else’s input? Are you surprised at the end that a valuable change cannot be delivered, because others didn’t do their job? It’s not your fault! Really? Well, if you failed, pay more attention to impact analysis. Create and check business processes, dependencies on departments, teams, and roles. To capture software component dependencies – have a clear logical architecture view (e.g., UML components model). Track which features are delivered by different teams.

You didn’t take care of your business

Maybe you knew that there’s another team’s input you need to wait for. But you did nothing before the deadline to make sure it will be delivered on time. Well, well. To make things happen, you need to act preemptively. Take the initiative in advance. Check what’s the status. Are they aware that they need to deliver something?

You don’t talk to each other

Maybe you knew that there’s a dependency. You’ve tracked who should deliver something for you. You know that they know about it (have it somewhere in their backlog or a todo list). But have you informed them how important the change is? Sometimes people don’t work on tasks because they don’t realize that someone is waiting for it. Talk to each other. Tell them that your changes need to work together to deliver a valuable outcome. Tell them when you plan to be ready with yours. Tell them when you expect their part to be ready. Have they heard you? Have they understood? Do they agree?

You don’t compare your points of view

Let’s assume you’ve successfully communicated your urgent need for the team’s work outcome. Have they agreed? If the change is not that relevant for them as for you, compare your points of view. Don’t end with “It’s important for us” and “But for us, it’s not”. Explain why you think so. What’s the reason you have evaluated the task as important and urgent? Which criteria have the other team took into account? Have you considered value for the business? Deadlines promised to customers? Risk to the company? Make sure you have the same criteria for evaluating the priority. And the same facts, measures, and numbers. How much risk, loss, or revenue are we talking about? Do we agree now? Have they changed their priorities? Or have you changed yours?

It may happen that they have agreed with you about the general priority, but they have something even more important on their todo list. If this is the case, maybe you only need to understand this?

You miss a common reference

Sometimes you get stuck in the discussion on priorities. It’s crucial for you but of little meaning for others. What to do with this? Well, maybe you need an instance above you to reveal the truth? After all, you don’t work for yourself. You deliver value for the whole product (if you work on a software component) or for the whole company (being one of the departments).

Ask your chief product owner about the relevance of the change combined with your teams outcomes. Where is the change planned in the overall backlog? Where is it on the roadmap? How does it fit the product vision? When has the outcome been promised to customers? Or what’s the risk for the whole product if we do not solve the issue urgently?

If there is no simple answer, you probably need to gather information from different departments, check a few facts, calculate the risk or value. Provide the information to decision-makers, ask for priorities decision criteria, and suggest the best way to assign priorities. Let them make the decision.

Who should do this?

Of course, you can say that if another team will not deliver their changes, it’s not your problem. And it’s not your responsibility. A product owner should decide, give priority, and make sure that the value will be delivered at the right time together with other teams outcomes. You can say that the other team didn’t do their job. Or that some managers failed.

Yeah. You can say so. But for what? It doesn’t bring us closer to the solution, right? And where’s your commitment? Especially when you wanted to be agile.

Take the initiative to solve such issues proactively. The product will benefit. The company will have a solution. The customers will have the value. And you’ll behave like a real professional being hired to solve complex matters.

Having said that, if it’s really not your job to care for such things on a daily basis – you have a product owner, a chief product owner or a manager – communicate the expectations openly and directly to the person. He or she needs to have a clear message that something was expected from the role, and employees don’t get clear information about priorities, the roadmap, or the product vision. Maybe they will understand and react immediately to deliver what you need. Maybe they will need some time or support. If they refuse – talk to other roles on a similar level – maybe they will be your allies to make the priorities clear in your company. For the sake of your product value being delivered on time.

Good luck! I wish that your changes will move higher in the other team’s backlog. And if not – I hope that you’ll understand why and will agree that this is better for the company.