Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
At the end of a project, there aren't enough story points to fill a two-week Sprint based on the velocity of the team.
The average velocity of the Development Team is actually 40 points per Sprint. In the Product Backlog there are just 20 points remaining to be completed.
Should we start this final Sprint as a standard two-week Sprint, no matter the amount of points remaining, or should we use a quick one-week Sprint in this case?
In my team, if the backlog was exhausted, we always had the following to fall back on:
Quite simply, start the Sprint with what you have.
However, your Product Owner (and the business) must learn the lesson that the pipeline of work is never finished. Run an ad-hoc retrospective to discuss how you ended up in a situation woth redundant cycle times.
Work out your average story completion per Sprint (prob somewhere between 8 and 14). Now you know what the PO/BA has to produce every timebox just to maintain velocity. In order to increase the backlog they need to be producing at least 14-18 stories per Sprint plus bugs and refactoring or tehnical debt artifacts.
(Adjust your figures to suit).
Scrum did not eradicate the pipeline of work; requirements must still be gathered mercilessly, we just learn from the Sprint Reviews and collect them as late as possible to improve the chances of success and relevance.
Your question is phrased in a way that may lead to good answers that aren't quite on target for your specific use case. You say:
[A]t the ending of a project there aren't enough story points to fill a 2 weeks sprint based on the velocity of the team.
So, your question is really about how to handle the planning and Sprint length for the terminal Sprint in a project. The short version of my answer is to favor predictable cadence over utilization or potential cost savings, and I explain why in more detail below.
In general, the goal of a Sprint is to meet the Sprint Goal, not to operate at some target velocity. So, the canonically correct answer is to put as many Product Backlog Items (PBIs) into the Sprint as required to meet the current Sprint Goal without exceeding your team’s sustainable capacity.
However, your question is really asking about the last expected Sprint of a project. Unless there are overriding business reasons, I typically recommend keeping the Sprint cadence intact for the following reasons:
In Scrum, the project isn't done when the Product Backlog is empty. It is complete when the Product Owner declares the product "good enough" that no further resources need to be expended. If necessary, the Product Owner can always declare an Early Termination and close out the project outside the normal cadence. This ensures that any deviation from cadence is seen as a framework escape hatch with visible costs or savings for the business, rather than reducing predictability.
Something is not right here.
The Product Backlog is an ordered list of everything that is known to be needed in the product. - The official Scrum Guide
It is almost inconceivable that everything that is needed only amounts to half a Sprint's worth of effort!
Perhaps you meant that of all the many items comprising the Product Backlog, only half a Sprint's worth meet the team's definition of ready? In this case, the Product Owner is not doing their job properly and the Development Team and Scrum Master are failing to hold the PO accountable for their failing here.
There is a story in Scrum, possibly apocryphal, of a company where, if the PO had not done their job properly and there were not enough work ready to play, the development team were allowed to go to the beach, and made sure they nosily passed the CEO's office on the way. Certainly a the rule of a Scrum Team I worked on was that if there was no ready work then we were to sit with our feet up on our desks. Although this sounds silly, the idea in Scrum is to make impediments visible and sitting around with feet up on desks sends out a very clear message, as does stampeding outside the CEO's office, I imagine. Of course, developers should be aware of their own responsibility as regards preparing Product Backlog items.
A practical approach might be to take all the ready work into the Sprint Backlog, with the aim to finish it all well before then end of the Sprint, and plan to use the remaining time in assisting the PO in getting more items ready for the next few Sprints. There should ideally be three or four Sprint's worth of PBIs that are ready at all times (and this should be achievable after a few iterations where Sprints are purposely finished early). Any more than this would probably amount to waste.
