How to manage stakeholder expectations when they keep on raising the bar

Question

Long story short, we are building a product and I have introduced then implemented the Scrum framework for product management. It has been working extremely well, and my team have done an amazing job.

The problem that I am having now, is that the main stakeholder is starting to get feature hungry to the point that the quality of deliverables is getting affected from an increased amount of items in the sprint.

Every time we do a good job, i.e. meet the sprint, the following week, the stakeholder then asks for more features. He feels that because we met the sprint, we can do more work the following week.

(Right now, he wants 3 features delivered per week)

My team then have to make up for this by upping their velocity. Eventually it has got to a point, where in one sprint we've had the kitchen sink thrown at us, and are expected to deliver triple amount of features relative to previous sprints. Due to the increased velocity that also means more bugs are appearing from features being rushed to production.

I am now in a situation when we are starting to fall behind on our sprints, with my co workers complaining that the workload is too much. I am also getting a lot more heat from the stakeholder for not completing all of the work that has been promised. At our next team meeting, I am think about talking to my stakeholder with the dev team about this, is this a good idea?

How can I handle this?

Answer 1

I actually have to disagree to some extent with David Espina. It is essential in Scrum to understand who owns which piece of the process.

• The Product Owner owns the Product Backlog. It is their job to prioritize the highest-value items at the top, to express their vision clearly to the Scrum Development Team, and to ensure that high value is being produced.
• The Development Team owns the Sprint Backlog. It is not in the PO (or any stakeholder's) purview to dictate what goes in to each Sprint -- in fact, that works directly against a good implementation of Scrum.
• The Scrum Master owns the Process. Whether it's you, Bobo2000, or someone else, to truly and effectively adopt Scrum in your organization the ScrumMaster needs to step in and guide the stakeholders and PO on the proper application of Scrum here.

By letting the PO (or, worse, a Stakeholder) dictate what makes it into a Sprint, you're diminishing the effectiveness of the team and putting the quality of your work at risk, as you've already noted in your post. This isn't to say that the ScrumMaster or Product Owner can't encourage the team to take more on or even guide them towards an aggressive Sprint Commit, but no one but the the team can commit an item to the Sprint Backlog.

In your shoes, I'd take some time to explain to stakeholders and POs that, hey, look at how much more we're getting done with Scrum -- you can't expect a miracle every Sprint. Velocity will generally increase, but sometimes it will decrease as well (whether the team makes a bad estimate or something is a "heavy" 8 instead of a "light" 8 for instance.) I'd tell them that we need to let the Development team do what they do best and trust the team to commit as much as they are able to a Sprint without jeopardizing the quality of the features that are being delivered.

Answer 2

I'm not quite who is pushing your team. You or the stake holder?

1: obviously any team needs to be constantly encouraged and challenged to achieve more and become more productive.

2: again obviously, regardless of 'what scrum says' deadlines matter if you want to get paid.

But! The dev team should be estimating the tasks on the back log and the velocity from the previous sprint should give you an estimate of how many tasks 'are in' the next sprint.

If the team are pressured to make lower estimates, it doesnt change the amount of work done, just the velocity number.

If the stakeholder is happy with more features and maybe less testing or less detail on each feature then thats their call and should be reflected in the stories. We all know that the last 10% of a story usualy takes 90% of the time.

If you or the stakeholder are directly pressuring the team to work harder or faster or longer hours thats just a management call on whether you think they are slacking or not.

Your scrum master should protect the team from this kind of direct interaction with the stakeholder though.

Answer 3

Raising the bar is a good thing. You should get behind this and continue pushing for more. Adding challenges to a team causes the team to figure out how to meet those challenges, and many times a very pessimistic team who predicts 'it cannot be done' gets it done. Somehow, teams adapt and innovate.

You also mitigate things like Parkinson's Law and Student Syndrome when you constantly challenge a team that believes 'it cannot be done.'

And I agree this is not with out cost and risk. You need to monitor those things and watch team morale, defect density issues, stakeholder complaints when their expectations are not met, etc. I think you'd be surprised, however, how many of those costs and risks do not actually materialize when you think they would.

It is interesting about planning values and stakeholder expectations. Plan for 2 features and achieve them in a given time period. Plan for 4 and get 3 in the same time period. The first one you met a goal. The second one you missed your goal. But which is actually better?

EDIT: To @bobo2000's comment: I would expect there would be a point of diminishing returns. In my observations, that point is further out than what many believe or predict. Nevertheless, if you think you're at that point, then you need to get really comfortable with telling your customer 'No'. If you choose to say yes to the challenge, then you need escalate in a very formal and loud way the risks you see, e.g., it is very likely we will not achieve all the objectives this sprint, or we may likely see an uptick in Sev 1 and 2 defects this go around. At some point, you need to begin controlling the conversation. Your customer is going to push and push because they look at it from a 'maximizing benefit for every $ spent' point of view. Say no and escalate risk. This is part of your job as a PM! Good luck.

@Rubberduck: Increased defects and missed deadlines could mean you have reached capacity if you have enough observations to rule out normal cause. Else, you may have a false positive. Both are probabilistic driven by many stochastic drivers. Increasing defects by itself does not say much. If 10% defect rate was expected, they have been performing at say 4%, and then they increase to 6%, does this suggest over capacity?

And your comment about confidence and process is exactly my point. If a team can improve its capacity by improving its procedures, then it was not at capacity to begin with.

Teams can adapt to challenges by way of innovation. If you don't force a challenge, teams will not innovate or adapt. In fact, they degrade...Parkinson's!