What's your take on "splitting" stories/tasks?

[MelissaPi1]

Recently, I’ve had a few conversations with people about the concept of splitting tasks/stories. Some teams want to “get credit” for the work done towards a work item (or they are using the task to count hours used up), but they also need to continue on the task in the next iteration, so they feel like they need two stories to represent the work. Or, they have done a part of the work needed, and now it needs to go to some other team, and then it will come back for more work in a later iteration. There are a few rich nuggets in here that we could discuss, such as the "getting credit" concept in Agile, and what's the right use of splitting stories.

I tend to reserve “splitting stories” as an action that is taken when refining the work, that the work is larger than the iteration it is being planned in. However, having to frequently split stories after the work begins speaks to the higher level processes that team, or teams-of-teams, use to create value. If more than one team needs to work on one task, then perhaps the task should really be a higher level object, and it should contain smaller bits of incremental value. And, teams may need to be reorganized or connected in different ways, in order to start and finish the work in a more collaborative, focused way.

So, I have a few questions for you: How are your teams "getting credit" for work items completed? How do you handle constant splitting or carrying over? Have you done any value stream mapping exercises?

Please always share the kind of team that you're working on, since we have many types - marketing, ops, IT, etc.

Thank you!!

[Sheri_Whitten]

This is a great question that I hope gets some great replies! I'm interested in how this is handled, since we are working through our mock setup for Agile. I created a great Agile-Kanban process for a team of 1 person, and it works splendidly since he's responsible for everything 😄 Now, my team of 7 creatives and 7 marketers would like an Agile process too, since it's way more streamlined than our current waterfall setup. We're just not sure how to divvy up the tasks and/or assignments to know who's responsible for what, in order to make this work.