|
What to do when a sprint is finished early? At the moment our Scrum team works off stories from the backlog, if the sprint is finished early. What happens with stories taken from the backlog? Will the stories be added to the current Sprint ? If yes, what if these stories won't be finished in time. Is the Sprint failed then? |
|||||||||||||||||
|
|
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.. |
|||
|
|
|
Working on stretch or future sprint backlog items seems to be the common thing to do, which makes a lot of sense if your sprint backlog items are small enough and clearly defined. However, backlog items that may place the "done" code into a "no longer done" state should be avoided. If the sprint is truly finished, tag it, prepare it for delivery, deliver it, and put your source code repositories into the "next sprint" state so there's no risk that late sprint changes will put delivery at risk. |
|||
|
|
|
For us a Sprint never ends early. We only increased our velocity or solved the problem in a way that makes us get more work done in the sprint. Saying that we always have a backlog of items that are prioritized in order of importance by our product owners. When any team can fit more work into the sprint it is very easy for them to see what to do next on the list that will fit positively into the sprints remaining time given their velocity. This avoids any downtime by the group waiting for discussions with Product Owner/Scrum Master on what should be done next. Our Product Owners and Scrum Masters keep on top of this list so there is always more work waiting to be put into the next sprint (or current one if time allowed.) |
|||
|
|
|
What my team does is pull tasks in from the backlog that are reasonably small enough to complete with respect to how early we finished. If we're done with that, we give our QA team time to catch up with their testing, and the developers get a "free day" - we can use this to look into other issues not related to the current sprint, topics we want to research, configure/reconfigure our environments, etc. Don't put a whole ton of work in just because you've finished early. Stick to what your team has committed to do in this sprint, and if extra work gets finished, that's an awesome plus. |
|||
|
|
|
I'd encourage slack to be used for personal improvement. Sure, pull in stories from the backlog, but make sure you spend some time on yourselves: learn a new language, practice your craft with a kata, refactor some stuff, tweak, refine or write new tools to help you out, go and talk to a stakeholder, colleague or client, find out what your QA team does, take time to understand how your UX process works. There is a huge list of things you can do that will provide value to your business and yourself AND improve your velocity or the amount of quality value you provide that don't involve pulling things from a backlog, try those first. |
|||
|
|
