Let's say my team's velocity is 50 and for the next release, we need to complete a 500 worth of user story points. My sprint length is 2 weeks. So if I divided 500 by 50 I need to spend 10 sprints to complete the work (entire scope).

But the stakeholders are asking to complete the same scope (500 worth of user story) before that timeline.

What kind of steps can one take to overcome this situation??

  • Why do the stakeholders want the same scope delivered faster? (Outside of them being impatient cheapskates, that is)
    – Erik
    Commented Nov 20, 2018 at 15:08
  • 2
    A planed marketing event is happening before we complete the release so stakeholders need to complete the release before that event.
    – Pesil
    Commented Nov 20, 2018 at 16:22

2 Answers 2


There is a baked in supposition that you must do all 500 points of scope in order to meet the user's needs. In Scrum, the first thing we would do is to challenge this assumption. By focusing on meeting needs rather than doing work, we can often find simpler solutions or identify things that aren't really needed.

Now, there are two other questions in here:

  • How can a team get faster?
  • How do I go faster than a team can go?

For helping the team go faster, the team should be having a retrospective and looking for improvements each sprint. However, any way of working reaches a peak level of efficiency and you have to change approaches of work to get more speed out of the team. This is great, but it is also dangerous. Any change to the way of working will slow the team down while they are adapting to it and it's possible that they won't get it right the first time (or second). This should be done at a time when teams can absorb a slow-down in order to gain improved speed later.

We can also add teams. Adding people to a project is complex. You would think that if one team was completing 50 points, two would complete 100, but they won't. They have overhead of working together, not to mention that there is a ramp-up time and will slow down the other team during that period. Again, this does have to be done carefully.


Adding to Daniel's answer:

It is dangerous to assume that you won't add stories over a period of 10 sprints.

This could happen for several reasons:

  • Feedback received at your sprint reviews may turn in to rework or new work
  • Technical problems may only become apparent when you start working on stories

It is also worth noting that velocity can go down as well as up. Sickness is just one of many potential causes of this.

Committing to deliver everything by the deadline could easily turn into a death march.

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.