Remaining PBI not filling up the Sprint.
A situation arises where we have for example 21 Story points currently planned for a product. Now, suppose we plan for 3 sprints based on a velocity of 7. the team manages to complete 12 story points by the end of the 2nd sprint. The team predicts that they can handle another 6 story points in Sprint 3. So, 3 story points remain. The team is confident that the 3 story points won't fill up a whole new sprint. They suggest to the scrum master that Sprint 3 shall be extended a little longer to fit in the 3 story points as well !! (Scrum Master knows that that's just wrong as per Scrum, as it impacts the velocity, etc).
What do you think they should do in this situation? If the team happens to complete 6 story points by the end of the 3rd sprint, and the 3 story points indeed do remain to be done, shall they start a new sprint with just 3 story points? Or shall they God-forbid extend the sprint? :) The remaining 3-story point story is quite important too (not as important as prior stories though), so it's ideal to have it ready for release ASAP (rather than wait until an uncommitted sprint is over).
Note that this is very similar to an actual situation I am facing as a Scrum Master / PO. There's a lot of pressure from a lead developer on the team to extend the sprint and be "flexible". In light of this, my suggestion is to keep the sprint length the same, as 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.
I'm not sure if this is the best approach as I am still thinking over it. What do you guys think?
> ...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.
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?"
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