Why do we split backlog items (stories)?

[Pat O]

I have been running my own schedule in version one while creating
tools to enhance our process. My routine at the end of a sprint is to
move (drag and drop) all my open work to the next sprint. I have
found through the Docs and our project leads that they split backlog
items at the end of a sprint. A look through this forum tells me that
one should split backlogs to get credit for the work done in the "old"
sprint.

What is meant by this?

Pat O
Cognex, Corp.

[Kevin S.]

Pat-

Splitting a story is an interesting agile debate (not necessarily a
tool/v1 debate). Based on my training/experience-

Good time to split a story-
Story -> Allow user to login
End of sprint -> User can login by manually typing username/pwd, but
system won't remember them the next time they return.
Outcome -> Release software as is, split story into "user can login"
and "User can login w/o entering username",
get credit for first but not second.

Bad time to split a story-
Story -> Allow user to login
End of sprint -> Stored procedures are done, but UI isn't.
Outcome -> split story into back-end and front-end work to get
credit for work completed. Let DB move on.

This is bad because it can't be delivered. It destroys the
"functioning software" line in the agile manifesto. The team can't
get credit for work unless it is "done" and adding business value to
the user/customer.

These examples are simplified for this conversation, but many times it
is not this black and white. Unfortunately, this second approach is
done way too many times.

Hope this helps,

Kevin Schlabach
Project Coordinator, Strategic Development
Beyond.com, Inc.

[Nick Maselli]

Pat,

I think the question is more V1 specific, referencing the "Split Backlog
Item" feature.

At the end of an iteration it is possible that not all of the scheduled
work was completed. From a V1 administrative point of view, you have a
couple of options.

1) Move the entire backlog item into the next iteration. The result is
one backlog item being moved around within iterations.
2) Split the backlog item. The result is two backlog items, one
representing what was done, and the other representing what is left to
do.

If you move the backlog item (as per option 1), you are essentially
removing the history from the previous iteration. When you attempt to
review previous iterations it will appear as if the work was never done,
as the backlog item now exists solely in another iteration.

If you split the backlog item (as per option 2), you leave behind what
effort was done in the previous iteration, and the remainder is put into
a second backlog item to represent what is left to do. When you attempt
to review previous iterations, you will see that work was done in
previous iterations.

For historical reference, splitting backlog items can add value.

For V1 backlog item ease of maintenance, moving entire backlog items can
add value.

I think in the end your company needs to come up with a model that fits
your needs from a working perspective, as well as a reporting
perspective.

Hope this helps!
____________________________
Nick Maselli

[Pat O]

On Jun 4, 10:38 am, "Nick Maselli" <Nick.Mase...@guideworkstv.com>
wrote:
...

> If you move the backlog item (as per option 1), you are essentially
> removing the history from the previous iteration.  When you attempt to
> review previous iterations it will appear as if the work was never done,
> as the backlog item now exists solely in another iteration.

...

> Hope this helps!
> ____________________________
> Nick Maselli
>

Is it true that the work no longer shows up in the previous sprint? I
suspect that it will not show up in the new sprint either as the date
the work was done is outside the new sprint. Is there someone from
VersionOne that can look at the backend and tells us how this works
for sure?

Pat O
Cognex, Corp.

[Kevin S.]

Thanks for your description, because as a new V1 user/implementer,
this is important aid for my group also. I'm glad you shared and I
think you are correct based on my usage.

But... a tool is just a tool and I intentionally gave insight to the
philosophy. After all, we shouldn't do things in a tool to "game" the
system and make our reporting work... we should use the tool to enable
our philosophy (and supporting methodology).

Based on my work with the ObjectMentor group in my last company, we
had decided that option 1 was the only acceptable option. We were
taught in XP/Scrum that
- an agile team can't get credit unless it is DONE (according to the
customer Product Owner)
- only the customer/Product Owner normally has the right to split
stories (since this changes scope and priority)
- a started story was always carried into the next sprint to be
completed (unless it was descoped).


On Jun 4, 11:38 am, "Nick Maselli" <Nick.Mase...@guideworkstv.com>
wrote: