Splitting up stories

There are a number of indication:
- If a team is inconsistent in its estimate. This means that the item is to complex to render a unified estimation.
- If a item is estimated "big". "Big" in relation to the usual amount of story-point / item-point / t-shirt-sized / ... the team is able to deliver within a sprint. Rule of thumb: In a sprint a team should be able to deliver three or more items.


If we a going to multi-team scrum:
- If different teams cannot agree upon one estimate for a single PBI - assuming that the different teams had already found a common basis for joint PBI estimation. This indicate, that either the item isn't suited to be delivered by all teams (the customer feature, this PBI is addressing spans over multiple teams with very different team-profiles) and is therefore kind of pre-destined for only a small set of teams or the complexity is very different in the vertical slices.

Has anybody made the experience that you split up stories, and in sprint planning the dev team clips them together again? It seemed kind of weird to me...

Inconsistency in the estimation is something very common I guess. It’s usually a sign that the story isn’t well understood (yet). In this case I would expect differences in estimation, let the team talk discuss it and hopefully come to a consensus, estimation-wise.
Despite all of this, it still remain a best guess, because the reality is that the team have no clue in how big the story actually is.

Usually what I do is set up a threshold with my teams. We agreed that all stories bigger than 5 points is considered a “really big guess” so the team needs to split it up. It’s actually crafted in our DoD as

“Items can’t be bigger than 5 points to be included in the sprint”
The best way to motivate your team is “to make a game out of it”.
A “game show” where the team needs to split the stories up in the smallest possible way :)

Before a Development Team accept a story onto their Sprint Backlog, they must be satisfied that they can actually complete it. There's no point in a team trying to action a story if they know from the outset that it will only end up blocked. A common example is where the team do not fully own their process and will be dependent upon another team for part of the work to be done.

If a story does contain such a source of impediment, it can be worthwhile splitting the story up into component parts that the team *can* action. For example, if a story will become dependent upon another team part way through, consider splitting it into "before" and "after" stories. The "before" story could deliver value to the other team (so they can do their part of the work) while the "after" story delivers business value to the client.

This story-splitting approach allows a team to wrap impediments, and progress the work that they are actually in a position to do, when they are able to do it. However, it is not something to be done lightly as the value provided by "before" stories can become rather contrived. The more artificial the value being supplied to another team, the more likely it is that the associated capability needs to be brought in-house so the original story can be wholly completed.

It’s actually crafted in our DoD as
“Items can’t be bigger than 5 points to be included in the sprint”

Isn't the definition of ready a better place for this? If you accidentally include an 8 point story and it gets done except the rule that it can't be bigger than 5 points, what do you do? You can never shift it to "done"...

Isn't the definition of ready a better place for this? If you accidentally include an 8 point story and it gets done except the rule that it can't be bigger than 5 points, what do you do? You can never shift it to "done"...

Woops... my bad... I ment the Definition of Ready :)