Split Stories - Unfinished and Continued - Any trail to trace Continued story from Unfinished one?

[Raghavendra Kulkarni]

Hello Rally SMEs,

I have a question around how can we find information through API on Continued story using Unfinished story number or vice-versa whenever we split stories. For eg: I have story US123, when the sprint closes, if the work is not complete, we split US123 and we two stories out of it 
1) US123 stays US123 but [Continued] gets pre-pended to name of story
2)US456 (new story) gets created in current sprint and [Unfinished] gets pre-pended to name of story

How I can find out associated continued story number using [Unfinished] story number. I looked at revision history, scanned through API response fields of hierarchical reqt API but didn't seem to find.

Any guidance/help would be appreciated,

Thank you,
Raghavendra​

------------------------------
Regards,
Raghu
------------------------------

[Mitch Goldman]

As far as I know, you can't.  It would be nice if Rally noted it in the revision history or created a dependency between the stories, but it doesn't.
Also, get ready for people at Rally to tell you that you shouldn't be splitting stories and how bad of a practice that is, despite them providing that function.
In reality, and despite best practices, story splitting is needed at times. But on the records trail side of things, Rally falls short here.

[Sheila Olds]

Following!  This has been an issue with our teams as well.  I'd also love an indicator to show "Unfinished" or "Continued" as sometimes teammates remove the Unfinished or Continued prefix from the title.  Gets more confusing when a story moves multiple times.  

I'd also love a way to keep the "unfinished" story from moving to Accepted and/or a way to automatically remove them from the feature/release.  There's a lot of manual work and sometimes (very often) teams get confused and end up double counting points.

I know that the perfect solution is to have teams finish the work they put in the iteration.  Until we live in this perfect world :), it would be great to have this procedure be easier.

Thanks!

[Raghavendra Kulkarni]

Thanks @Sheila Olds and @Mitch Goldman. Good to know I am not the only one. To Mitch's point on creating dependencies, there is manual way but we don't follow that practice in our org. But if either of you are interested it is that when we split the story, there is small checkbox to make one story parent of another (parent/child​​ between stories)

Although from what I know visually we don't see any reference of one story in another unless manually added in notes or discussion, I am still hoping if someone can enlighten if this relationship can be determined through Lookback API or WSAPI!​

------------------------------
Regards,
Raghu
------------------------------

[Sagi Gabay]

Hi Raghavendra,

You are correct that a Split isn't an event that can later be traced, unlike for example when you move a story between schedule states. In other words, there is no recording in Rally that a story is actually being split. This in it of itself will not be a bad enhancement request. If you want to pursue that then please follow this process.

One way you can keep track of split stories is to use a tag (named: "Split" or similar...). This is explained in this document.

From a WSAPI and LBAPI standpoints:
The short answer is: there isn't any accurate way to find it cause that event isn't stored as such (as said). However, if you keep the name prefixes, i.e: [unfinished] and [continued] then you should be able to run queries where the Name field contains these strings. As long as you keep these prefixes then WSAPI will be able to find them. If you later rename them, then LBAPI should be able to find it based on that the original name included these prefixes.   I would think that using a Tag is easier though.

We realize there isn't a great answer here. I hope this helps. 

Please let us know.
Sagi

[Jarrod Reed]

Hello,

There is an app out there that was built for a specific customer which tracks split stories the way Sagi mentioned. It assumes the names haven't changed post-split, so it will be accurate as long as the naming convention practices are followed. IMO this is a worthy enhancement request. Until then, perhaps this app could also be modified to display original and split stories for you in a way that addresses your current need. This is not a perfect response, but I hope it helps in some small way, and I encourage all of you to request an enhancement.

https://github.com/RallyTechServices/patio-dashboard-apps/tree/master/split-story-dashboard​

------------------------------
Jarrod Reed
Broadcom AOD | RALLY
------------------------------

[Raghavendra Kulkarni]

Hello @Sagi Gabay and @Jarrod Reed

First of all, thank you for the responses and my apologies for the delay in acknowledgment. Yes, currently we are not changing the default [Unfinished] and [Continued] pattern in name of stories and that is how we are determining how many stories/how much % we split. Our next step was to understand why do teams split stories and to investigate this, we typically do it story by story manually. Get the Unfinished and Continued story #, go to [Continued] story  and understand the sequence of events on tasks/discussion/notes and see if any of these (estimate, actuals, no of tasks, test cases, no of discussions, no of notes and so on) could have influenced the split.​ We now want to scale it and see if we can automatically retrieve these details for every split story to understand if there is one or two areas we need to focus.  As Sagi mentioned, if split isn't an event that is traced, then what we are looking for impossible unless we manually put a tag of continued story # in [Unfinished] story using which we can retrieve details/history of continued story through WSAPI. 

I think I am going to leave it at that and explore if we can put a feature enhancement request(thanks Saby for the link). And thanks Jarrod for sharing the github repository of Split Story Dashboard, it looks great, we have something similar with more related information which we are currently using but will share the git repo with team.​​​​

Thanks again!

Regards,
Raghavendra

------------------------------
Regards,
Raghu
------------------------------