The Value of Collapse?

Mike Burrows writes:

It occurs to me that we often expand (decompose) big features into a list of smaller ones but don't tend to collapse them back onto the original ticket later.

Is this:

1. Common?
2. Good? (I can think of some reasons why it might be)
3. Bad? (likewise)
4. Depends? (on what?)

Some within the kanbandev group believe that collapsing smaller features back into larger ones doesn't add a lot of value. Kurt Häusler writes:

I don't like expand and collapse. I do like expanding larger requirements into many small stories, right at the beginning, before they even enter the system, and keeping them small throughout the whole process. I guess that isn't always possible, but I think it is better to strive for that, than conveniently make use of larger MMFs or even mini-projects just because reducing transaction costs is too difficult, or because customers can't test "unfinished" features, or because people just generally tend to have a "think big and complex" mindset.

Simple thin vertical slices of functionality, all the way across the value stream, FTW.

Ron Jeffries writes:

XP used to recommend breaking stories down into tasks. Many of us no longer recommend that: we recommend slicing them into smaller stories instead.

There is no explicit concept of "collapse" in XP, because there is no need for it.

Siddharta Govindaraj sees some value in collapse, however:

This works if the whole viewpoint is centered around the development team alone. You slice stories and deploy them one by one and there is no need to collapse. But, when looking beyond the dev team, many steps on the end to end stream do operate on the big feature. So although you might be deploying small stories in dev, there is still a need to collapse it back when the big feature moves to the next stage.

Ron Jeffries replies:

What next stage do you have in mind? In Scrum and XP, for example, the team produces a deployable increment of software (including all the necessary documentation) every iteration.

I get that from the kanban viewpoint, one just models what is. But if what is, is a big expand / collapse, one is almost certainly modeling waste, buffers, and delays which can be removed.

And Paul Beckford writes:

Key ingredients here are small increments, feedback and iteration. When you do these things then the idea of collapse no longer makes sense at any level of abstraction other then the smallest increment (e.g. a slice, which to me is a small group of acceptance criteria, taking perhaps half a day).

[Ed. - For more perspectives on this discussion, please see the article "The Further Value of Collapse".]