12

Background

Scenario

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.

Capacity & Backlog

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.

Question

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?

3
  • OP can you clarify - is there any project left to be done or has it come to an end? Jul 16, 2018 at 19:16
  • Can you fill the sprint with any useful investigation or technical-debt cleanup tasks? Whenever I find time, I make effort to clean up the codebase wherever possible.
    – ESR
    Jul 17, 2018 at 5:06
  • I've tried to clarify your post by breaking the scenario and question up into sections, as well as bringing the fact that it's the final sprint of the project to the forefront. If this conflicts with your authorial intentions, please edit or revert the question as necessary.
    – Todd A. Jacobs
    Jul 19, 2018 at 12:04

4 Answers 4

18

In my team, if the backlog was exhausted, we always had the following to fall back on:

  1. The team can invest time and create a prioritized backlog of technical / architectural debt in your systems
  2. Work on technical debt items created using point 1 (above).
  3. Improve the automated continuous integration and continuous process. In the world of infrastructure as code (IAC), there is always more to aim for. This again is a technical task where the team can write and update the backlog.
  4. Technology upgrades. There is always the next version of Visual Studio or database server or JavaScript library you could be upgrading.
  5. Technical proof of concepts. Talk to business and identify areas which could benefit from technical brains.
  6. Organize a hackathon or personal coding time whenever people are free, so they can deliver pet projects which help your company or community.
  7. Improve the unit testing process. There is always untested areas of code in the current sprint and past sprint.
  8. Create or improve automated functional, regression, and integration tests.
  9. Ask your team for ideas. Usually teams have ideas on what's the best way to tackle a problem (including backlog deficit problems)...
5
  • Exactly, there is always more to do and operating from a situation of slack is beneficial to the team and the project.
    – Alper
    Jul 16, 2018 at 10:07
  • +1 The only change I'd make is place 'Ask your team for ideas' at the top of the list.
    – John_C
    Jul 16, 2018 at 12:26
  • 1
    Sure, if the Sprint Backlog is exhausted. But the PO is referring to the Product Backlog.
    – onedaywhen
    Jul 16, 2018 at 15:02
  • I've seen a similar list here on pm.stackexchange which I think is better.
    – onedaywhen
    Jul 16, 2018 at 15:04
  • Like onedaywhen said...it is not the Devs have slack in the Sprint; it is that the product backlog is empty of play ready stories. Not ideal... Jul 16, 2018 at 16:42
5

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.

  • Are stories not play ready?
  • Has the backlog been exhausted?
  • Are no further requirements known?
  • Where are the stories represent refactoring work?
  • Do you have a bucket of "engineering stuff" that has value to developers but not necessarily to customers directly?
  • Do you have defects to be fixed?

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.

4

TL;DR

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.

Plan Around Goals, Not Velocity

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.

Cadence for Terminal Sprints

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:

  1. A key goal of Scrum is predictable delivery and labor-cost planning, so keeping the delivery cadence has inherent value.
  2. Setting stakeholder expectations of a shorter Sprint might backfire if unexpected work is uncovered within the iteration, or if the team mis-estimates during Sprint Planning.
  3. Rescheduling stakeholders for the Sprint Review outside of the normal cadence is often more trouble than it's worth, especially with a large pool of stakeholders who also have other demands on their time. NB: This type of last-minute rescheduling can be a significant cost to the business that a predictable cadence is inherently designed to solve. Trying to shave a few days of already-scheduled labor from being charged to the project is frequently a false economy for the business, and may indicate project-centric (rather than business-centric) thinking.
  4. New work might get placed onto the Product Backlog as a result of the inspect-and-adapt cycle embodied by the Sprint Review, or as bugs or technical debt are uncovered.

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.

2
  • Hi Todd - I think the OP has a pipeline problem. The PO has simply not managed the backlog and now nothing is play ready... Jul 16, 2018 at 16:40
  • 1
    @Venture2099 That wasn't what I got out of the question. The fact that it's the final Sprint of the project is buried in the original post. That's why I call it out in my tl;dr, as I think it changes the scope and context of the question. Without that, I think the interpretation that it's a backlog refinement problem would be the right one.
    – Todd A. Jacobs
    Jul 16, 2018 at 18:46
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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