|
Key Takeaways
|
- Discover probable causes for teams reaching the end of an iteration and having uncompleted user stories.
- Find out about four different approaches for managing these unfinished user stories.
- Gain insights into recommended options, required steps, and potential affects.
|
Context
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. In addition, they need to understand why this might be happening so they can improve in the future.
Root causes of incomplete work
Teams may see a pattern emerging in which 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 commitments for future iterations.
Common causes include:
- Everyone is working on their own individual user stories.
- The team is not really operating as a team, but 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. This relates to the definition of ready.
- Distractions are pulling the focus away from 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 user stories without undue interruption?
- The team is over planning and not using historical velocity to drive predicted velocity of the next iteration.
- Teams are being asked to change scope mid-iteration due to shifting business priorities. (This is a “no-no” from an Agile perspective; there should be no scope changes once the iteration begins.)
Options
NOTE: The recommended and not recommended options are the opinion of the author, a senior Agile coach. Rally can support any and all of these options.
1. Move the story (recommended)
Moving the story by changing the scheduled iteration allows teams to easily handle unfinished work. However, this prevents them from seeing accurate historical iteration plans and assessing whether they met their iteration commitments.
Actions:
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 (for example, to change the task owner) for the work to be completed in the next iteration.
- There is no need to change any linked defects or test cases.
Impact:
- The plan estimate value for the moved story will no longer be reflected in the iteration. This affects 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.
- 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. It will also display the replanned work as not completed within the iteration.
- 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 affected 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 (that is, 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).
2. Split the story (do not accept the unfinished 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.
Actions:
- 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).
- Optionally, use the gear tool to move each completed task from the Unfinished story to the Continued story. This keeps all history of completed work attached to the original story.
- 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 accepted.
- Keep the unfinished story as Completed, but not Accepted and the continued story as Defined or In-Progress, depending on whether 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.
Impact:
- 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 (Insight not currently used).
- 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. Split the story (accept and zero out the unfinished story)
Splitting the story allows teams to preserve some historical information but it has an impact on Rally metrics.
Actions:
- 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.
- Zero out the plan estimate on the unfinished story and keep the original plan estimate on the continued story. Generally speaking, Agile practice dictates that teams get full velocity credit for the work in the iteration in which the work is accepted.
- Mark the unfinished story as 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.
- There are no post-split actions to take.
Impact:
- The plan estimate value for the unfinished story will no longer be reflected in the iteration. This has an impact on 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.
- In the velocity/enhanced velocity chart, the plan estimate values of unscheduled stories will not show as unaccepted or accepted after the iteration ends.
- The cumulative flow diagram will accurately reflect the scope each day of the iteration but will show the change of scope when the unfinished stories are split. (Look for a “pinched corner” on the cumulative flow diagram where the scope decreased when the unfinished story’s plan estimate was zeroed out on the last day of the iteration.)
- By the nature of the split process, split stories will show up on the iteration and release scope change reports, since the unfinished story is actually a new story being created as a placeholder. The release scope will not be affected as long as the continued story is scheduled for the same release.
- There is no need to remove the unfinished story from its associated feature since it has been marked as accepted with a plan estimate of zero.
- Unfinished stories should have no negative impacts on Insights metrics, such as “Time in Process,” since these stories are accepted with a plan estimate of zero (Insight not currently).
- 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.
4. Copy the story (not recommended)
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 has an impact on Insights metrics, such as “Time in Process,” since the copy of the story will never be accepted.
