AnsweredAssumed Answered

Accepting split stories across iterations within a feature.

Question asked by acavender@tradewestsystems.com on Jul 31, 2014
Latest reply on Aug 4, 2014 by acavender@tradewestsystems.com
Feature tracking of user stories seems to be skewed when one uses the Split action on a user story to continue unfinished work in another iteration.  The Feature maintains a count of user stories, and more importantly, the percentage of accepted user stories to the total story point count.  This gives us a very useful measure of how close we are to completion of a feature.  However, when we have a user story that was not completed in a single iteration, then we typically use the Split feature, to make a clone of the user story for the next iteration, and also use the default setting to create a parent for the new stories to link them together.

We run into issues when the user story is part of a feature because we cannot accept the unfinished user story, lest it modify the Iteration Velocity.  However, if the story remains unaccepted, then the feature will always report short of 100% complete.  This forces the product owner/scrum master to delve into the feature to see if there is still truly unscheduled work, or if they were just the unfinished orphans.

Unfortunately, Rally will not permit us to set Accepted on the parent user story directly (which is not tied to an iteration, so it would not directly affect velocity).  We could also not use the parenting feature of Split and keep the stories independent.  Then we could un-parent (or is it de-parent?) the unfinished story from the feature.  This is undesirable as we then lose the work that was done in the iteration for that part of the feature.  (Consider the original story was 3 points and was not accepted, and the continued story is estimated at 1 point.  If we unbind the original story from the feature and only have the continuation as a child of the feature, then the feature is now shorted 2 story points.)

Does anyone have advice on how to better manage this situation?  It would be ideal if we could keep our feature completion tally accurate without having to compromise our Iteration Velocity.

Outcomes