Remaining PBI not filling up the Sprint.

> ...I don't believe in extending Sprints whatsoever.
> But, rather than starting a new SPRINT of the
> same length, finish that 3 story point outside
> of a sprint and have a short review right after
> (e.g. this 3 SP won't count in our burndown
> and velocity reports), just for the sake of the
> urgency of releasing it ASAP.

Why not allow a new Sprint to start with the same length, even if only a 3 pointer is forecast for delivery? Why don't you want it to figure in burndowns and velocity? What actual problem do you hope will be solved by conducting this work outside of a Sprint timebox?

The thing is, that 3 story point story, for example, can/will be finished before half-way through the sprint. So what will the team do for the rest of the sprint if we are to stick to the same actual sprint length? Normally in these scenarios you add more work from the backlog to the sprint, but the backlog of that product would be empty in that case, and a new product would be the next focus for this team, with a backlog refinement as the next step.

So, my point is, the team could technically handle more than 3 SP in that sprint, and the reason the velocity would be 3 for that sprint is simply lack of work. I prefer not to have this impact the overall velocity calculation.

On the other hand, that 3-sp story is relatively important. So it should be released as soon as possible rather than wait for the end of the sprint to do the review.

In reality, in my scenario, there's actually some lower priority work that can still be done in the extra sprint to keep the team busy, but then again, that feature is more important, and it's prefered to release that an hit a firm limited release window than delay it and release a few weeks after.

So you see, the problem is we want to review and release that story on day X after it's done, rather than wait for day X+Y on which the sprint time expires.

> The thing is, that 3 story point story, for example,
> can/will be finished before half-way through the sprint.
> So what will the team do for the rest of the sprint
> if we are to stick to the same actual sprint length?

Assuming that the Goal for that Sprint has been met once the 3-pointer is complete, the team can do whatever they want. They could even start work on a completely different initiative. The Sprint timebox would simply be left to expire.

> I prefer not to have this impact the overall velocity calculation.

Why not? What harm could it do, if there are no more forecasts to be made for that product?

> ...the problem is we want to review and release
> that story on day X after it's done, rather than wait
> for day X+Y on which the sprint time expires.

You can do that. You can hold a review and effect a release of the increment as soon as the Sprint Goal has been met. That's the time to do it, so value does not depreciate. The Sprint timebox can't be abbreviated, but it can be left to expire.

Nima,

You are correct, in that is is highly discouraged to adjust sprint lengths to accommodate sprint work. Managing the 3-pointer outside of the sprint doesn't gain you or your team anything except create a lot of unneeded administrative overhead and management.

To address your immediate concern, a team does not have to wait until the end of a sprint to release work into production. If a story is finished, satisfies a team's DoD, and is production-ready, the option should always be there to release to prod at any time afterwards, even in the middle of the sprint.

So we're apparently doing some hand-wringing over what amounts to a few days. Keep in mind that the team may still complete the 6 points in your Sprint 3 early, and have capacity to also complete the 3-pointer that you are worried about.

Reviewing your scenario, there are more pressing questions which I believe may be leading to your issue:

1) Why are you performing as both the SM and the PO? This is a very unhealthy dynamic (conflict of interest) that Scrum expressly disallows.

2) Why aren't there groomed stories in the backlog besides the 3-pointer that would finish up that product version release? If the team were diligent in grooming each sprint, there would not be a shortfall of ready-for-sprint stories, even if there were another "project" involved.

3) Why couldn't that 4th sprint involve the 3-pointer, along with all of the grooming activities needed to prepare stories for the next "product" for future sprints? This grooming work needs to take place anyway, and should have already taken place. Stop getting hung up on the team velocity metric as an indicator of what a team should be doing. Velocity helps a team understand how much the may be able to do, and it helps the Product Owner estimate how much work may get done over an extended period of time, and plan accordingly.

You are suffering some pain as a result of not "priming the pump". Good discussion for your retrospective - "What can we do to ensure that there is always a supply of groomed ready-for-sprint stories to be offered to the team?"

Hi Nima,

Is the Product Backlog not adding to sustain the lifecycle of the product. The scenario that you have given as example projects or suits a situation where your team is focusing on completing a feature. Though they follow the events of Scrum. The sustainability part of the product is missed where new opportunities are not explored 

I still feel that the old remnants of  waterfall still being adhered to where the Development team is lead by a single person demanding on behalf of the team to extent sprint timeline that violates the idea of Scrum