What is the right way to move items to the next sprint?

[Max Bower]

Sometimes it happens that we have to move items out of the sprint.

There are two scenarios:

1) During the sprint we realized that one item was much bigger than expected, so another item will never be started. Should this other item stay in the sprint till the end? Or should it be moved to the backlog/next sprint when we realized this?

2) It is end day of sprint and some items are not finished.
for us it is the Support Bucket item (Is in the sprint with a time bucket on it, if there is a concrete request from Support we have to create an subtask for that and put infos in that subtask and close it if support is finished). Not all Sub-tasks are finished, so actually it has to be moved to the next sprint.
But this way the Support Bucket item will grow bigger and bigger each sprint - also I'm not sure about the impact on statistics calculated based on this item(logged time in sprint on diffrent kind of task)

What would be the best way of handling the support items (unfortunately they can not wait till the next sprint start to be handled, and some cant be closed till the end of the sprint - thats within their natur).

[Carlos Garcia Navarro]

Hi Max,

These are my comments to your two scenarios:

1) It depends.  If this "large" story has the highest priority maybe the team should still work on it, as the other items are less important.  In general I don't think that re-estimating stories is a good idea, but your scenario seems to be an example of a story where the estimate is way off, so I would re-estimate the story, and maybe break it down. If there are pieces of the original story that must be delivered by the end of the current sprint I would make sure that they stay in the current sprint. Otherwise you can keep the new stories result of the break-down into the backlog.

2) If I understand correctly, the Support bucket is unplanned work. I'd recommend to have a story of 0 points where the Support items are added and tracked in terms of hours.  By the end of the sprint you'll have the number of hours that are used for unplanned work and you can use these data (or an average of these data) to do capacity planning. I.e, if you know the amount of time that the team members have available for a sprint, subtract the number of hours predicted for unplanned work (support items), and plan to allocate them to the rest for the stories. In general, capacity planning is based on time while velocity is based on points (and you can do both!). While the team estimate stories in points, during the sprint planning tasks (or sub-tasks) can be added to the story and they can be estimated in terms of hours.  Make sure that the total amount of hours for the tasks/sub-tasks doesn't exceed the total number of hours available minus the ones reserved for unplanned work. I always have an unplanned story (with 0 points) in the sprint which contains the unplanned tasks/sub-tasks that were completed during the sprint.

Hope it helps,

Carlos

[Max Bower]

thanks for the reply.

ad1)
The Question is more about stories/other items that are not started (and are ranked lower). On half time of the sprint I know that we wont make them -> it is impossible - no matter if they stay in the sprint or not.
Should these Items stay int he sprint?

ad2)
That explains roughly what we currently do (for capacity planing we also use a productivity factor).
The actual problem is, that these support (sub)tasks not always  are finished by the end of the sprint. We got these support-bucket-Action-Item containing subtasks for different support requests (e.g. a customer support ticket).
But not all of them can be closed by end of sprint because we wait for response of the other party.
How wot handle them by the end of the sprint?

- Move the bucket to next sprint (will also move closed subtaks and look likes wired, because than this bucket will always be open and more and more time on it)
- close the subtasks and clone to next sprint without the logged time (do we lose a bit history)?
??

[Carlos Garcia Navarro]

Hi Max,

ad1) If the stories are not started and the team doesn't plan on work on them during the current sprint, then yes, I would remove them from the sprint and place then in the backlog in the right place depending on the priority.  If the team will work on part of the story, then I would break the story down and keep the piece that the team will work on, otherwise the velocity may not be computed correctly.

ad2)My recommendation is to close the bucket (or as I see it,, a 0 point story for unplanned work) at the end of the sprint, and to start a new one with the beginning of each sprint. The goal is to keep track of the number of hours spent for unplanned work during the sprint, in order to have an average per sprint.  If e.g. the sub-task (under the 0 point story unplanned work) "working with supplier" is not done by the end of sprint 4, but you spent 5h on it during the sprint, you can rename it as "working with supplier during sprint 4", set the time to 4 h, and create a new sub-task under the 0p unplanned work story for sprint 5, called "working with supplier during sprint 5", and set the hours to as many as you spend during the sprint 5.

Hope it helps,

Carlos

[Max Bower]

Hi carlos, sorry for long delay.

ad1) Actually the stories should be already so small that they could not be broken down into more parts ... but yes velocity calculation would be impacted ... on the other side -> nothing is finished no velocity

2) Yes that's exactly what I struggling. Always creating the sub-tasks again is exhausting.