Do not clean up Tasks
DO NOT Clean up done Tasks for unfinished Stories while switching to next Sprint.
As a team member I would like to have full information about all Tasks that were created for Stories unfinished in previous Sprint. Currently we loose important information about what was done, and I am not sure if everything that was to be done was really done. Information about these finished Tasks is lost for ever - because in past Sprints report there is no information about not finished Stories (and report is ok, because there should not be such information). In most cases unfinished Stories from previous Sprint are realized during first days of next Sprint, so in my opinion information about done tasks should not be lost and should be shown also in current Sprint.
This idea is also connected with our concept for "having story DONE". For every story we create additional tasks "DEV verification" and "TEST verification". Which are performed after all "normal" tasks are finished. "DEV verification" is in fact code review done by developer who was not or least involved in story "normal" tasks. "TEST verification" is performed by tester who checks if done functionality is in line with Story description and tests. These two checks and all fixes which are consequences of these checks gives us sureness of having story really DONE and ready for Sprint review. For "DEV verification" information about all done tasks is essential.
There was iss548 "Clean up tasks when kicking Story from Sprint" that is marked as closed for 0.21. But I can not remember what was that. It could be opposite of this idea as now tasks are cleaned up :)
Statement from Kunagi Team
We have had several issues/requests concerning handling Task of Stories that are not finished during the Sprint, i.e. rejected by the Product Owner when the Sprint timebox finishes.
Our current approach is to
- remove Tasks from the Story
- log their former existance to the Sprint Log
Stories that move back to the Product Backlog after a Sprint have to be re-estimated by the Team before being pulled to another Sprint again. This allows the Team to incorporate knowledge about the complexity of the Story and knowledge about changes in the implementation that affect (e.g. reduce) the complexity of the Story. The baseline for the implementation of the Story is thus based on the current state of the implementation (i.e. after the last Sprint in which the Story failed to be completed).
Thus, Tasks may be obsolete and can be confusing if they appear on the Whiteboard.
This is the best solution that we could come up with so far. If you disagree or have good ideas on how to improve our current approach, please let us know in the comments.
Status
Issue is closed.
Comments
Tue, Feb 21, 2012, 12:14 by Krzysztof
Is there any decision with this issue?
Tue, Feb 21, 2012, 14:37 by artjom (PO,T)
I have my hands full at the moment, that's why I only treat new Issues superficially.
We are, however, currently working on making Stories of past Sprints accesible (sto187). In the process, we will have to think about a way to handle "attached" entities, like Comments and Tasks.
As soon as we done that and I clean up the Issue inbox, I will come back to you.
Sorry for any inconvenience.
Mon, Feb 27, 2012, 10:29 by Krzysztof
No problem, thanks for information. It is really great that you decided to realize sto187. Big thanks for that.
Fri, Aug 24, 2012, 14:29 by artjom (PO,T)
@Krzysztof: May I ask how you handle this problem in the meantime? We have had different configurations of keeping and cleaning up Tasks and have not yet found a pleasing solution.