Hi Mitch,
I am slightly reluctant to join in this conversation as my views might seem slightly controversial. So please forgive me if I don't explain myself well enough. I am going to deviate from the UI implementation issue. I will leave that to Product Management.
When I started at Rally six years ago, we had a great debate about: "To split, or not to split". There are pros and cons to both ways as seen from either side. The one thing that convinced me to go one way was the additional debate we had about: "Roughly right, not precisely wrong". As you might have already deduced, I fell on the side of not splitting stories at all. Splitting a story requires a leap of faith that what you have completed as tasks are a consistent indication of the completion rate of the remaining tasks. Having been a developer, I know that the brown stuff hits the fan all too often to say that this is 100% true.
If splitting stories doesn't happen, then there are a few things that get highlighted and some of the changes you might want to bring about help improve behaviours and actually improve predictability.
If I start with the 'roughly right' bit. How accurate do you need you sprint stats to be? If you were 90% accurate on a sprint by sprint basis, would that be sufficient? Most companies I work with do planning over a longer period, e.g. a quarter. So, that is 5/6 sprints. If you are 99% accurate over a 6-sprint period, is that sufficient? It all comes down to what you are going to do with the data that you are taking the time to precisely create. This app may help you with the average:
https://github.com/nikantonelli/TeamVelocityMany of my colleagues have wondered about my presentation where I use the phrase "Take the time it takes, so that it takes less time". I use this to talk about the sprint planning session. There are no shortcuts to taking the time to understand an issue, to break it down into individual chunks, each of which you can easily get your head around. Splitting stories should then become the exception, not the norm. Splitting is still needed for those "Oh S...!" moments. If we have 5-7 people in a team each with 4 stories a sprint and we have to deal with 1 or 2 unfinished stories, then we are still 90% (or more) accurate
So what happens to stories that aren't finished? My recommendation is just to move them to the next sprint and finish them off. My experience is that people take the split continuation story and put it top of the priority list as the first thing to do. If you can accept that there was a dip in the accepted story points of the previous iteration, you will find that the 'average' corrects itself when you move the 'whole' story into the next iteration.
Applying Lean thinking here.... why do it?
------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------
Original Message:
Sent: 01-02-2020 10:10 AM
From: Mitch Goldman
Subject: Where did split go?
Prior to the UI "upgrade" last month, checking the box next to a user story in the iteration status screen would allow you to choose the split option. This was used extensively at the end of a sprint to break up a story; leaving finished tasks in the old sprint and moving unfinished ones into the new sprint. The iteration status screen is a great tool for facilitating this, since it's on that screen where you can filter down to see what work in the ending sprint is not complete. However, with the new UI, when you check the box on a story, "split" is no longer an option available to the user.