Effectively Splitting User Stories

Assuming that the story is already functionally complete and satisfies the INVEST criteria, why split it at all? Why are you considering doing so? Is no team able to implement the item unless it is split into separate technical concerns?

I don't see any objections to this, it could be useful to split it up so that during the scrum events it's clear what you're talking about. Especially at the moments when users/customers or the PO are involved. If you want to split it up to divide the work, I'd be against it - then it would be more efficient to just work on the same story with multiple people.

If the story does not satisfy the INVEST criteria – particularly the S for Small – and so there is indeed a need to split it…

1) Splitting it by just the API since it can be used by some other team, and then another story to consume the API through the UI component?

• Will another team (or customer) benefit from being able to use the API sooner?
• If so, could there be an opportunity to use feedback about the API, to influence development of the UI component?
• How much complexity does it add for multiple teams to work together on this feature?
• How much waste is introduced by this approach, in terms of extra co-ordination or upfront planning, handing off to another team to continue the work, potential rework when it is discovered that the first component doesn't work as expected, potential delays in getting a working feature to market?

  2) Splitting it but it will still be worked on on the same sprint?

• Can splitting in such a way increase the value of "Done" software delivered in a single Increment?
• How likely is this to increase or decrease the length of time before a customer uses the feature, and provides meaningful feedback?
• Do you plan to release the split parts separately, even if they are done in the same sprint?

Rather than split the story by components, is there an opportunity to split by test cases, or acceptance criteria?

If this can be achieved in a way that allows "Done" software to be delivered, this could help in releasing something to the customer early, and shortening the amount of time it takes to get the first customer feedback.

Ian Mitchell, the team thinks the story is not small since there are a number of scenarios that we are considering, but the team also thinks that they can finish the story in one sprint.

Niels Dimmers I understand what you are saying. Also, the API part is independent of the UI and can be tested by introducing testing endpoints/commands since it is not exposed publicly.

Simon Mayer for item 1, definitely the other teams can use the API as soon as we're done with it even the sprint is still on-going and therefore, we can use their feedback to further improve the API. No other team will work on the story (UI + API) so it won't really introduce complexity in terms of external coordination. For item 2, the team is leaning towards delivering the story pieces by pieces - which, the way I see it now, is technically slicing it into smaller story. I have also thought about splitting it by test cases, but I think it will raise the same dilemma if it's still necessary to do that since the story will be worked on on the same sprint.



After I posted this question, I just discovered that another reason the team doesn't want to create a new story is because the requirement is owned by someone outside the Scrum Team (yes, even I can't believe that they've even thought of doing that - and yes, as a Scrum Master, I have raised it as a problem) so they don't want to talk to that person just to see if they can split the user stories.