Working with Stakeholders Who Won’t Take No for an Answer

Sign up to receive weekly tips like the one below from Mike Cohn to Help You Succeed with Agile here: https://www.mountaingoatsoftware.com/email-tips

Do your stakeholders have a hard time accepting a “no” from the team? Or put another way, does your team have a hard time telling the stakeholders that what they want is impossible? If the answer to either of those questions is yes, you are not alone.

I’ve found two techniques useful in communicating a “no” so that stakeholders listen and understand.

First, the team should establish a track record of planning projects accurately and meeting most commitments.

You don’t need to be perfect, but if a team meets most of its commitments, the business is more likely to listen when the team says something is impossible.

Second, when telling a stakeholder that a proposed date cannot be achieved, offer alternatives. For example,

  • By what date could the functionality be delivered?
  • Are there especially challenging requirements that could be relaxed to meet the deadline?
  • What could be done to make the date feasible? More people? Stop using the team for second-level support?

Stakeholders often want more than can be delivered by some date. This shouldn’t be the team’s problem alone.

Wanting more than can be delivered must be viewed as a shared problem. A solution can only be found by the business and team working together.

When stakeholders trust the team’s commitment and work together with team members to find solutions, they all succeed with agile.

Why Agile Teams Should Estimate at Two Different Levels

It is very common for agile teams, especially Scrum teams, to estimate both their product backlog and sprint backlogs. In this article, Mike Cohn will address:

  • Why estimating both the product backlog and sprint backlog can be useful even though it seems redundant
  • Why teams should estimate the two backlogs in different units
  • When teams should estimate
  • Whether all teams should estimate

Although I think you should not try to use hours for estimation, I agree using different valuations for an estimation is best. I find using T-shirt sizes for PBIs and Story Points for SBIs work well.

Read the complete article here, and also take note of some excellent comments at the bottom: https://www.mountaingoatsoftware.com/blog/why-agile-teams-should-estimate-at-two-different-levels