Sprint Backlog Task Estimates – Understanding the Hours in Scrum

First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical).

But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the sprint being short is that new work can be added to the next sprint (after it has been correctly prioritized) without affecting the overall project timeline (multiple sprints).

But if the work is critical for one of the tasks in this sprint you have two options.

1. Add new item to the sprint.
   BUT remove an equivalently sized item from the sprint.
2. Drop the item that was badly planned from this sprint (so you can properly plan it in the next sprint).
   • Adding in an alternative (of appropriate size) from the top of the product backlog (which should have be in priority order from your sprint planning meeting).
   • Or when all sprint items are finished allow dev's to pick up slack from the product backlog.

So I am in the camp that you should probably not modify the sprint backlog. But you have to take into account the situation there may be exceptional circumstance. In most cases I would go with options 2 and let devs pick up the slack with tasks from the backlog.

Then in the next planning meeting the new task will be appropriately analysed and added to the sprint (as appropriate).

Remember the sprint is short and just the mark of the next drop not the end of the development cycle. The product owner would have to be very desperate for a feature that they could not wait for the end of the next sprint.

Bring something from the project backlog into the sprint (after discussions with scrum master and project owner).

The size of the item you undertake will depend on how much time you have. If there is nothing small enough create a sub-task of a bigger task to get it started (ie do some of the preliminary work).

Alternatively create some tasks that make the code base better. I have never seen a code base that could not be improved in some way. Review some code add more unit tests etc..