0

I just joined a team that is working towards being agile. 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. However during Sprint Refinement, they are asked to contribute to the points of a story and more often than not, their points are different from the developers and QA's points. I feel a lot of time and energy is wasted negotiating the points with the support staff because we have to justify and explain technical details in order to convince them of our estimates.

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? Their questions do not enhance the understanding of the story.

We have now been forced to have multiple refinements to accommodate their input and I feel it is a waste of time. What can I do?

1
  • 1
    Support staff is driven by requests changing daily. That is the anti-thesis to Scrum. They would be better served by something like Kanban. Are you sure it is a good idea to have support staff in your Scrum team, is is that maybe just because how the departments were structured before switching to Scrum?
    – nvoigt
    Commented May 14 at 6:14

2 Answers 2

5

The answer has nothing to do with agile methods, Scrum, agility, or story points. The answer lies in good estimation practices, which are equally applicable across the spectrum of agile to plan-driven methods, regardless of what estimation methods are used.

Based on our knowledge and experience in estimating, we know that the people who are best suited to estimate the work are the people who will be doing the work. The estimates of other people, including people who are knowledgeable about the work and how to get it done but won't be involved in doing it, aren't useful.

If the support staff are not going to be active participants in completing the work, there's no need to have them involved in estimating the work. Even if they had the knowledge and expertise to do the work, their way of doing it may not be how the team plans on doing it and their perspectives could degrade the usefulness of the estimate.

3

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:

  1. Agile development needs to include a clear Definition of Done for each Increment.

  2. If you have support staff on your team, then the whole Scrum Team needs to be involved in delivering the Increment.

  3. Your Product Backlog or Definition of Done probably lacks clearly-defined items related to post-deployment activities and Day 2 operations.

  4. Development agility often requires a test-first mind set, which is why you have QA testers on the team.

  5. 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:

  1. Adopt a "support-first" mind set, similar to the test-first mind set required for TDD/BDD.
  2. Involve the T-shaped support people in debugging or pair programming whenever possible.
  3. 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.
  4. 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."
  5. 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.

4
  • I am questioning the value of their point estimates for work they WILL NOT do, not dismissing them as team members! Developers ensure code maintainability using defined standards. A technical handoff to the support staff is part of our definition of done. The idea that every member is a developer is false in reality. Not everyone can develop software, and no amount of paired programming or knowledge sharing will alter that fact. Support staff participate in other team ceremonies. Refraining from sharing their opinions on story pointing doesn't diminish their contribution to the teams goals. Commented May 14 at 19:04
  • @user6284097 The point is that whole-team efforts are additive. The work you need to do to make sure the Increment is supportable by them, and the work they need to do to plan, develop, document, or whatever is needed to integrate and support the Increment all adds up. All the work needs to be part of the estimate, not just the programming part. Non-programmers probably shouldn't be estimating programming effort, but they absolutely should be contributing to the overall estimate of a well-crafted Product Backlog item that represents a vertical slice involving the whole team.
    – Todd A. Jacobs
    Commented May 14 at 19:41
  • The effort of what the support staff need to do "support the Increment" is not comparable to the development and qa effort necessary for the increment. The support staff effort is subsumed by the points assigned by qa and dev. Commented May 15 at 1:15
  • @user6284097 No, that's exactly wrong. Just as they shouldn't be telling you how much effort something will take you to do, you have zero business saying how much effort something will take them. Work must be estimated by the people doing it, and if you aren't working collaboratively then the effort is additive: it's the sum of everyone's effort to get to "done" that matters. In addition, if they need things from you or vice versa, then that effort must be part of the estimate, too.
    – Todd A. Jacobs
    Commented May 15 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.