Splitting stories isn't always the best solution for your practices. Yet each method you might follow has it's own consequences and this article illuminates all the methods and their impacts on your data and reporting.
When a team gets to the end of an iteration and there are user stories that are not completed, they need to decide how to manage them. And, they need to understand why this might be happening so they can improve in the future.
Listed below are the three primary methods.
- Move the story--moving the story by changing the scheduled iteration allows teams to easily handle unfinished work, but prevents them from seeing accurate historical iteration plans and whether or not they met their iteration commitments
- Typically the story should get replanned to the next iteration.? When doing this, you should:
- Change the ?Iteration? on the story to the next iteration
- Keep the plan estimate value the same
- Zero out the task estimate and to-do hours for completed tasks so the estimate is not reflected in the burndown chart in the next iteration?
- Keep the actuals (if used) value on completed tasks to reflect the amount of work spent
- For tasks not started or in progress, no changes are needed
- It is okay to add tasks or modify existing tasks (e.g. change task owner) for the work to be completed in the next iteration
- There is no need to change any linked defects or test cases
Note: a tag or custom field can be used to track stories that were moved to help with reporting.? The lookback api could also be used to write a report that shows the scope change and calculates real % accepted and shows the replanned work as not completed within the iteration.
- The plan estimate value for the moved story will no longer be reflected in the iteration; this impacts several built-in Rally metrics:
- ?The % accepted on the iteration status and iteration summary page: these numbers? will inaccurately reflect the team?s ability to meet their iteration commitments since the unscheduled story is no longer accounted for
- The velocity/enhanced velocity chart - the plan estimate values of unscheduled stories will not show as unaccepted or accepted after the iteration ends
? ? ? 2. ?Split the story--splitting the story allows teams to preserve historical information on what work was planned for the iteration but not completed, but it has an impact on some Rally metrics and appears as release scope change when it really is not.
- The cumulative flow diagram will accurately reflect the scope each day of the iteration and will show the change of scope when the unfinished stories are replanned (look for a ?pinched corner? on the cumulative flow diagram where the scope decreased to match the accepted plan estimate value on the last day of the iteration)
- The release scope will not be impacted as long as the story continues to be scheduled for the same release
- As long as the story is replanned within the iteration time box (i.e. on or before the last day of the iteration), it will appear on the iteration scope change report as a removed story
- If the story has tasks in progress with the remaining to-do value less than the estimate, the burndown chart will reflect this difference on the first day of the iteration, making it seem that the team did more work that day than they actually did (since the work was really done in the previous iteration)
- Use the ?Split...? menu option in Rally to help with this process
- Keep any completed tasks on the ?Unfinished? story in the current iteration; move any defined and In-Progress tasks to the ?Continued? story (the split story action will do this for you automatically)
- Keep all test cases and active defects (defects in any state other than closed) linked to the continued story
- Keep the plan estimate as is on the unfinished and continued story.? Generally speaking, Agile practice dictates that teams get full velocity credit for the work in the iteration in which the work is completed
- Keep the unfinished story as Completed, but not Accepted and the continued story as Defined or In-Progress, depending on whether or not tasks are in progress.
- It is recommended to not use a parent story to link the completed and unfinished stories
- ?Post-split, it is important to change the release value of the unfinished story to ?none? to unschedule it and remove any parent story and feature associated with the story.?? The continued story will account for the entire scope of work in the release and feature.? The unfinished story is simply a placeholder for historical visibility into the iteration plan.
- The % accepted and velocity charts will correctly show the plan estimate value for the total scope of work committed to for the iteration
- If the unfinished story is not removed from the release, the release scope will be artificially inflated and the burn up chart will never reach 100% since the unfinished stories will never be accepted
- If the unfinished story is not removed from its parent story, the parent story scope will be artificially inflated and the burn up chart will never reach 100% since the unfinished story will never be accepted
- If the unfinished story is not removed from its associated feature, the feature scope will be artificially inflated and the burn up chart will never reach 100% since the unfinished story will never be accepted
- Unfinished stories will have a negative impact on Insights metrics such as ?Time in Process? since these stories will never be accepted
- Since all test cases remain with the continued story, the team loses visibility into any test results for that story in the original iteration
- If you are following a practice of logging defects for failed test cases in the iteration, any open defects linked to the story being moved will no longer be counted in the active defect count for the iteration; the defects will instead count as active defects in the next iteration until they are closed.
- By the nature of the split process, split stories will show up on the release scope change report as scope being added (since the unfinished story is actually a new story being created as a placeholder) and removed (when you subsequently unschedule the unfinished story from the release).
? ? ? 3. ?Copy the story- It is generally recommended to never handle unfinished work by creating a ?copy? of the user story.?? Some teams want to leave a ?copy? of the user story to show where it was originally planned, but this is effort-intensive because both the original and copied stories need to be ?cleaned up? to reflect the original work done and the work remaining. This is waste.? Copying stories also impacts Insights metrics such as ?Time in Process? since the copy of the story will never be accepted.
Teams may see a pattern emerging where multiple user stories remain incomplete at the end of an iteration. It is important for the team to understand why this is happening and adjust their Agile practices to try to improve on their iteration commitments for future iterations.
Common causes include:
- Everyone is working on their own individual user stories.
- Team is not really operating as a team, but is operating as a group of individuals. There?s not a lot of sharing of work going on, hence not a lot of help being asked for or received.
- There is too much work in progress. Lots of user stories get started, not all of them get finished; people are working on too many things at once.
- User stories are too big.
- User stories are not well understood, and it takes a lot of time to understand them.
- Dependencies were not considered or aligned before starting. Relates to Definition of Ready.
- Distractions are pulling focus away from the user stories. These distractions could include pulling people for other projects, too many meetings, or something else. The main question is this: Are we able to focus on the user stories without undue interruption?
- The team is over-planning and not using historical velocity to drive predicted velocity of the next iteration.
- The teams are being asked to change scope mid-iteration due to changing business priorities (this is a ?no-no? from an Agile perspective; there should be no scope changes once the iteration begins).