5

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?

  • 9
    The only entity which decides how much work goes to the sprint is Development team, not stakeholders. – MasterPJ May 6 '16 at 12:20
  • There are far better ways to increase "velocity" that are win-win, focused on empowering, trusting and supporting teams. Is it more difficult, and slower? Yep. – Jeff Lindsey May 9 '16 at 21:21
10

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.

  • 3
    After I posted this, I realised that part of the problem was in the sales process, we are letting customers dictate our sprints by adding 'enhancements' to what they originally had requested affecting the work in the sprint. When if they ordered a Pizza, they should get a Pizza based on their own specifications. If they want a variation they should wait until the cycle is over - is the correct way in doing it? – bobo2000 May 6 '16 at 15:40
  • Also if the development team decide what goes into each sprint, should they attend requirement gathering meetings? – bobo2000 May 6 '16 at 15:41
  • @bobo2000 Yes and yes. Unless the Sprint is terminated early and the Sprint Team returns to Sprint Planning, as a rule of thumb new scope should never be added to the current Sprint, especially from outside the Development Team. – Todd A. Jacobs May 6 '16 at 16:56
  • Sales process can definitely be a pain here -- you should check your story descriptions against what your sales team discussed with the customer and address discrepancies. In general, if the team finishes the work of the Sprint before the end, there's no problem with pulling in extra items, or using the time to refactor/QA the work done. – JDRoger May 6 '16 at 17:08
1

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.

-2

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!

  • Whilst I totally agree with you, at the same time it is becoming unrealistic, for example this week our sprint was cut short since we had a short week (public holiday on Monday), yet the work load was probably 1 and a half weeks worth, and in terms of priority they all seemed to be equally important for the stakeholder. – bobo2000 May 6 '16 at 10:40
  • 1
    If you use Product Backlog the priority should be clear, one item by one. In a list there is always only one item per line. – MasterPJ May 6 '16 at 14:06
  • My gut reaction is to downvote, because making the team move faster than its actual capacity will slow things down in the long run as the team piles on technical debt. On the other hand, you're correct that it's a good thing to raise the bar. You've just got to be careful not to raise it so far that you have to cheat to get over it. It'll burn you in the long run. – RubberDuck May 6 '16 at 16:51
  • 2
    @DavidEspina since pondered over all of this (thanks for your advice), but I think that the problem is how we are taking work on. For example: We are building a product and we have our own product roadmap to respect, lately instead of saying NO to doing every customer request straight away, the sales team are always taking it on and not letting them know that it cannot be done right away since we have our own product roadmap to respect, which is causing our sprints to be disrupted by an increased (unrealistic) workload . I want to tell the sales team, how can I do it non confrontational – bobo2000 May 8 '16 at 0:41
  • 1
    @DavidEspina an increase in defects and missed deadlines very much does indicate that they've hit their capacity. At least until they regain their confidence and improve their practices and process. As for managing the backlog, the customer should set priorities. The development team should be the ones saying "this is what we can get done by mm/dd/yyyy." How could a non-technical person know what's possible? The developers are the experts, they know what's do-able and what's not. The Product Owner section of the Scrum Guide is useful here. – RubberDuck May 8 '16 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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