How To Handle Spare Capacity At The End of A Sprint
How are others handling it when you are coming up on the end of a sprint and it is clear that all the committed items will be completed by the end of the sprint and the sprint goal will be met and some team members “don’t have anything to do”. I know that the team has the option to pull in additional items, but I feel that should only be done if the team is confident that the item can be completed within the sprint. Once you start creating carry-over that starts to dilute the sprint commitment. Some would argue that if it wasn’t included at the start of the sprint it isn’t “committed work” so it is OK to carry it over. I would prefer not to have any carry over as when you look back weeks or months later that distinction is lost.
Of course, the first thing would be to see if you could help with any item that is not done, but this is not always possible, not everything can be worked on in parallel to get it done sooner. Some other options would include creating or refining backlog items, working on research or documentation. However sometimes a team member wants to “get a head start” on something that has an almost certainty of being in the next sprint. The problem is how to make this work visible?
sometimes a team member wants to “get a head start” on something that has an almost certainty of being in the next sprint. The problem is how to make this work visible?
A sprint ends when the time-box for it expires. It is irrelevant whether or not work is completed. Why wouldn’t the updated forecast of work you refer to be included, and made transparent, in the corresponding Sprint Backlog?
all the committed items
Nope, all the forecasted items... Sprint Goals are committed to, items are forecasted.
should only be done if the team is confident that the item can be completed within the sprint
Why? Those are still a forecast, not a commitment
Some would argue that if it wasn’t included at the start of the sprint it isn’t “committed work”
I would argue that regardless if it is planned at the beginning of the sprint or pulled in later, it is never committed work
The problem is how to make this work visible?
Using the exact same way you collectively decided to make "regular" work visible
OK for me personally, I value the "spare time" very much. I ask the team(members) what they deem most valueable to them to spent the time on. That might be different each sprint. Innovation, prototyping of new ideas, extra backlog refinement, improving CI/CD or automated testing, they know best, right?
I like the question @Jerry Ward
We have the same problem , and team tends to pull in small bugs from PB. But most times by the end of the sprint we are not able to make them as Done and they are moved to the next Sprint.
I would agree with @Xander
Now , in your case these new items pulled by team are non committed to the sprint goal and some can be important to be investigated before the start of the next sprint. So, its fine if team pull in such items which they intend to have head start with. Sounds better plan for the next sprint.
Recently we started using this free capacity to refine the future PBIs , working on improving our build pipelines. All the interesting topics that we think can give us benefits in the long run than working on minor unfinished bugs. I mean bugs are important as well but we started giving prios to more beneficial topics.
Xander had the best answer in my opinion, Take it to the team.