-
Notifications
You must be signed in to change notification settings - Fork 0
Story Splitting (User Guide)
Other competing apps implement story splitting as a second-class citizen. In Atoll story splitting has been designed into the platform. Each story has parts associated with it- even a story that hasn't yet been split. So, as soon as a story split occurs there's a built-in association with the original story. This provides a few benefits- for example, the velocity computation can be more accurate. However, this does mean that users coming from these competing products will need to differentiate between this splitting techniques as described below.
- Continuation: A story should've been completed this sprint and it will need to continue into the next sprint(s).
- Refactoring: A story is too big and has multiple parts, so it will need to be split up into multiple stories.
This is really just the same story but the team couldn't finish it in one sprint, so they had to carry on into the next sprint. The problem with most other systems is that they make you turn this into multiple stories when it really isn't. That's a very simplistic view of what actually happens with you continue a story into another sprint.
What actually happens is that the tasks, that were done for the first part of the story, were done in the previous sprint so they should stay there. Also, since the story is continuing into the next sprint the team cannot yet claim the points associated with that story. However, a specific number of points worth of work has been completed- so the continued story can't really have the same "point value" anymore. So, Atoll takes the approach of allowing you to assign "remaining points" to a story in the new sprint.
An example:
Story #222, a 13 pointer titled As a PO, I can split an unfinished story, so that the team can continue work in the next sprint cannot be completed in sprint 261. It gets split to sprint 262 and the team estimates that they've completed 25% of it (just ~3 points)- so that leaves 10 points remaining. Part #1 has 3 of 13 completed, while Part #2 has 10 of 13 remaining.
It is possible to perform actions with these "story parts" similar to full stories, but a few rules apply when moving parts into and out of sprints. Moving parts out of a sprint to the product backlog will result in the "unallocated points" being calculated based on the first part that will be allocated to a sprint. For story #222, part #1 will show 3/13 in the backlog. When part #2 is also moved to the backlog it will still show 3/13 because that's the first part that will be allocated. Parts are grouped into a single story in the product backlog. After part #1 has been allocated, it will show 10/13. The reasoning behind this is that the same work is associated with that part. If it has tasks it will have the same tasks attached to it as it is moved around.
This could be grouped under "refinement" as well. Essentially, the story is too big as it is and it can be broken down into smaller parts. Unlike a "continuation" split, this type of splitting should only happen before work is done on the story.