Loading Profile...
Twitter,
Facebook, or email.
EMPLOYEE
What should I do with Product Backlog Items (and Tasks) that are unfinished at the end of Sprints?
Official
Response
-
Items which have not been completed in a sprint should be returned to the Product Backlog for re-prioritization by the Product Owner. In most Agile methods, "no partial credit" is the rule of thumb when dealing with partially completed work. In cases where the team does meet all acceptance criteria for the backlog item, the product owner should not split the item and give “partial credit” for the parts done. Agile best practice is to remove the item from the sprint and move it back to the Product Backlog.
What happens to the historical record of the work done in the sprint? First, tasks are disposable in Scrum since the team should be measured and evaluated based on whether sprint goals and product backlog item “done” criteria are met. There should be little harm in moving tasks out of sprints because the tasks do not create any meaningful metrics.
However, if tasks are important for other reasons, the suggested course is to create a duplicate backlog item in the product backlog. Then change the “backlog effort” of the original, undone product backlog item in the sprint to zero. This will keep a record of the tasks done, but have no impact on the total backlog effort outstanding in the release.
Reference: http://danube.com/blog/michaeljames/j...
-
Items which have not been completed in a sprint should be returned to the Product Backlog for re-prioritization by the Product Owner. In most Agile methods, "no partial credit" is the rule of thumb when dealing with partially completed work. In cases where the team does meet all acceptance criteria for the backlog item, the product owner should not split the item and give “partial credit” for the parts done. Agile best practice is to remove the item from the sprint and move it back to the Product Backlog.
What happens to the historical record of the work done in the sprint? First, tasks are disposable in Scrum since the team should be measured and evaluated based on whether sprint goals and product backlog item “done” criteria are met. There should be little harm in moving tasks out of sprints because the tasks do not create any meaningful metrics.
However, if tasks are important for other reasons, the suggested course is to create a duplicate backlog item in the product backlog. Then change the “backlog effort” of the original, undone product backlog item in the sprint to zero. This will keep a record of the tasks done, but have no impact on the total backlog effort outstanding in the release.
Reference: http://danube.com/blog/michaeljames/j...Comment -
-
While I share most of your views on the principles of "no partial credit" etc., as a project manager I feel that your product is severely lacking here.
Scrumworks needs to track the history of work. To do so, Scrumworks should duplicate the unfinished work items by default when a sprint is closed, but without "giving credit".
The current state of affairs does not offer the project manager the necessary support, and asking the user to duplicate tasks manually when the tool could easily do that automatically goes agains the very purpose of using a tool for scrums. -
-
Hi helgep,
I agree, this is something I have discussed with the Product Owner. I'm not sure what the status of the PBIs related to it are however.
Last time I spoke with him the idea was to have an option to leave a sort of "ghost" PBI + tasks behind as an option when moving a backlog item out of a sprint.
Currently, the only recommendation I have is to copy the backlog item (ctrl alt N with the backlog item open) and just don't put an estimate it in. Previously this wasn't a possibility because PBIs had to be estimated to be in a sprint, in one of the recent releases unestimated PBIs became something you could put into a sprint..
After that I copy the tasks into the the "new" backlog item I am leaving in the old sprint as a record. I usually tend to tag it with a theme also, like "unfinished". It is handy for reporting later.
It is a bit more time consuming than I would like, but it does work. I'll speak with the Product Owner regarding this topic again. I would like to see this feature put in place at the same time we put something similar in place for deleted PBIs. -
EMPLOYEE
