TL;DR
The team consists of developers, the maintenance/support staff and QA. Support staff's job is to keep the lights on, they never do any development...Why do people who are not even going to work on a story need to opine on the level of effort it will take to complete the story?
Your phrasing makes it clear that you don't consider the support people full members of your team. If you have support staff on your Scrum Team, then part of the Definition of Done is likely ensuring that each Increment is not only deployable, but also maintainable during "Day 2" operations and beyond.
It's also clear that there are some foundational misconceptions within your team about how an effective Scrum Team is supposed to work. Let's take a closer look at how Scrum is supposed to work, what some of the pragmatic issues likely are, and what you as a team can do to address those issues together.
Analysis and Recommendations
Many teams that are new to Scrum or other types of agility are used to "tossing things over the wall" at other people, or treating development as completely separate from testing, deployment, or maintenance. This appears to be your viewpoint.
This is a prima facie fallacy because:
Agile development needs to include a clear Definition of Done for each Increment.
If you have support staff on your team, then the whole Scrum Team needs to be involved in delivering the Increment.
Your Product Backlog or Definition of Done probably lacks clearly-defined items related to post-deployment activities and Day 2 operations.
Development agility often requires a test-first mind set, which is why you have QA testers on the team.
If you follow agile best practices, your Definition of Done should also include things necessary for Day 2 operations such as:
- Clear documentation about the software product, including support, maintenance, debugging, and usage.
- Explicit support and knowledge sharing for integration with your organization's logging and observability infrastructure.
- API or exception documentation.
If you're not taking the operational aspects of the product into account, then you're not delivering a functional Increment. In a team that's very new to Scrum you might have support/operations people who don't know how to ask for what they need, but the fact that they're inflating your estimates is a very clear indication that they think something is either missing or needs to be accounted for when estimating the work.
Team Members Are Never "Downstream"
If you and other Developers on the Scrum Team are treating the people with support skills as external to the team then you're doing Scrum wrong. Remember, while people might have different areas of expertise, there is no hierarchy in Scrum! If you're not the Product Owner or the Scrum Master, then you are a [Product] Developer. You might not be a software developer, but Scrum only has three roles, and in your case that clearly includes I-shaped, post-deployment team members.
Your job is not simply to deliver some piece of work and call it a day—or a Sprint, for that matter. Your job is to work together to build a useful Increment of a product, and in this case it seems clear that considering Day 2 operations as part of your planning is something that isn't being done or considered by some of the programmers as part of their collective responsibility as members of the Scrum Team.
Document, Collaborate, and Explain
If you've already built in extensive capabilities for logging, debugging, observability, traceability, auditability, and system recovery, then you've probably just failed to communicate that effectively to the rest of the team or the organization. That's potentially a large book of work and will largely fall on you and the other programmers to support the support team if you haven't been doing this all along.
Revisit the Team's Definition of Done
On the other hand, if the Scrum Team hasn't been delivering Increments of the product with these capabilities in mind, then it's something the whole team should consider as significant technical debt. How can anyone but the programmers support a system that is undocumented, or that doesn't have any levers for IT operations to pull when something isn't working right?
It's a collective responsibility for the Scrum Team, and not something the operations folks should have to wander off and try to figure out on their own. You have to collaborate on building a maintainable system, and that may mean rethinking what each Sprint needs to deliver in order to ensure maintainability.
One way to do that is to ensure that the plan the Scrum Team creates together during Sprint Planning includes the level-of-effort needed to produce this level of documentation and system transparency. That will certainly require collaboration between the programmers and the support members of the team, and while this will potentially reduce the team's capacity for delivering new features, it will increase the team's ability to routinely deliver supportable features. The latter is vastly more important from a business perspective.
Include Everyone in the Development Process
You say that the support staff on your team have no role in "development." That's either not true, or shouldn't be true. If operational support is part of what the team is supposed to deliver, then the whole Scrum Team (including the programmers) are responsible for ensuring that each Increment is supportable and maintainable.
Some ways you can assist with that include:
- Adopt a "support-first" mind set, similar to the test-first mind set required for TDD/BDD.
- Involve the T-shaped support people in debugging or pair programming whenever possible.
- If no one on the team is T-shaped, the Product Owner and the Developers need to budget capacity for code reading, internal demoes, "chaos engineering" or disaster recovery exercises, and other forms of cross-functional knowledge sharing that ensure that programmers on the team understand IT operations better, and that IT operations team members understand the system better.
- Make this overhead visible on the Product Backlog and the Sprint Backlog so that it's made clearly visible as necessary overhead for the project rather than something that can be swept under the rug as "someone else's problem."
- If the Scrum Team or the Developers are parceling out work piecemeal rather than collectively swarming over work, then you should address the process or training gaps on the team as part of a Sprint Retrospective. *NB: This is not about blame; it's about pointing out that the team has a problem that needs to be solved for the whole team.
In other words, you need to lose the "us vs. them" (or maybe even the "me vs. them") mindset that your teams seems to hold about operational considerations for the work that it's doing. If you're not doing some form of buzzword-only Scrum then everyone on the team should be working towards a single, cohesive goal each Sprint; the entire team is collectively accountable for reaching that goal! There's no such thing as a Scrum Team where you can individually "succeed" in meeting the Sprint Goal while the rest of the team is starved for information, resources, or collaborative support.
