During our sprint we discovered that we needed to finish some unforseen, but absolutely neccessary tasks to complete.
How do you handle these as best practice ? Should I create this task on the sprint backlog and put the completed hours in it ? Or should I add these extra hours to the task that I initially was working on ?
Unforseen tasks will always be there.
As a developer, please raise it in the upcoming Standup meeting (Daily Scrum). Make it visible on the scrum board. Make sure your Product Owner/Stakeholder knows this ad-hoc requirement. Ask your Product owner to de-commit the low-prio user story in order to accommodate such high-prio urgent tasks.
This will lead to consistent Velocity of the Team. Such ad-hoc tasks will be known to Product Owner so no conflict at the end of Sprint. Tasks with equivalent complexity will be de-committed, therefore developer will not be overloaded or pressurised.
The tasks that are created for a story during the sprint session are just the beginning . New task will often be identified as part of realizing a story. I typically suggest to add them if they are more than 3 hours. We don't track completed hours typically in a Scrum team, but we do put the effort remaining. This is useful since it updates the Sprint burndown report which we use to track progress toward the sprint. If it is a small task and that it make sense to add the work remaining as part of another task then that works too. I suggest to keep your tasks smaller than 2 days. If a task become bigger than 2 days of effort remaining, you should find ways to decompose it into smaller steps.
Martin Rajotte - Scrum Coach and TFS Expert at Incycle Software
There will always be unforeseen tasks. The cone of uncertainty is quite clear in that fact and scrum acknowledges this. Sprint planning is described as determining what to accomplish and a plan to get started.
Scrum has even removed the expectation of tasks and hours, because teams may well use a different mechanism such as ATDD to monitor their progress.
So, short answer: do what feels right for your team. The point is for you to discover your process.
First thing: If there's something that you have to do in order to complete the sprint, do it, and make sure to record it.
That means that if you are discovering a new task required to complete a story, add it to the story, make note of the increased remaining tasks (or hours) in your burndown chart, and mark it as unplanned work.
If this is a task that is unrelated to any story that you are currently committed to, you should (assuming that you really must) do it, record it, and mark it (unplanned). You should consider adding a story that describes the reason (who & why) you're doing it.
The important thing, is to analyze the unplanned work during your retrospective; you should strive to minimize these occurrences, by spending more effort on planning, and communicating the importance of the stability of the sprint (as may be the case).
In any case, I'd advise against a dogma of "we're agile / doing scrum, so we can't do it in this sprint". Be really agile, and inspect, learn and adapt.
