BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Further Value of Collapse

The Further Value of Collapse

This item in japanese

Bookmarks

Mike Burrows, a head of IT and Agile enthusiast, started a discussion on the Kanbandev group which has led the community to explore the Expand / Collapse pattern, look at how it's related to other analysis practices and terminology, and attempt to address some of the confusion which results from breaking down larger-scale requirements into smaller, incrementally deliverable pieces. The discussion was covered elsewhere on InfoQ, in an article which followed the viewpoints of many practitioners who see more value in expansion than collapse. However, many people found both aspects of the pattern useful.

Mike started with the question:

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 common? Good? Bad?

The discussion, now at well over a hundred posts, touched on the difference between MMF or Minimum Marketable Feature, and BVI or Business Value Increment, both of which have been used by the Lean and Kanban community to indicate a minimum deliverable. Chris Matts, creator of Feature Injection, explains:

Julian Everett came up with the term "Business Value Increment". It is infinitely better than MMF which is the term I stupidly introduced to the group a few millennia ago... a term that has been causing confusion ever since. The idea is if you deliver less functionality than the BVI, then you deliver no value to your business investor.

If your deliverable is smaller than the BVI, then you lose time to market as you have to then add extra work you had not considered. If the BVI is too large, you are not delivering things as early as you could.

Enterprise Agility expert Dennis Stevens explores two different ways of using the Expand / Collapse pattern, with the first expanding across several boards:

1. Program board coordinating multiple teams... Expand the BVI across multiple teams - each completing their portion of the work. Collapse the work back into the Program BVI so it can be delivered.

2. As a Story moves across a complex Kanban - it may decompose into different tasks for the different Kanban status. Delivery might expand to Analyze, Design, Test, Document, Develop... The BVI expands into multiple stories or tasks with collapse back into the BVI when that status is "Done".

Lean and Agile coach Eric Willeke responds with a blog post laying out the benefits of the Expand / Collapse pattern as he sees them:

  • Focus the team. One major benefit of expand/collapse is that it focuses more of the team on related tasks... If taken all the way, I should be able to see how my individual activity today rolls all the way up to my company’s True North.
  • Manage learning in progress. When you apply expand/collapse, keep an eye on the amount of stuff to "figure out" in each broken down item. The ones with lots of stuff to figure out will have the highest variability.
  • Manage abstractions. It’s far easier to have value and prioritization conversations about 5 large items than 50 (or 500) smaller items. On the other hand, <developers> need the detail to effectively track and deliver against the goals.
  • Triggering conversation. The mere act of decomposition is a value add activity. Scrum uses sprint planning and task estimation to drive these conversations, but dropping iterations doesn’t excuse you from the need to explore... as a group.
  • Enable Operational Languages. I’ve often heard about deep misunderstandings between "development" and "the business" because the two are speaking completely different languages while using the same words. This is only made more complicated when you introduce other groups as valued stakeholders, such as legal, finance, compliance and operations.

Eric finishes with this perspective:

There’s no expectation that you can clearly define what code you need when you pick up a task, you’re free to be a professional... The same logic should apply to the tasks to complete a story, the stories required to complete an epic, and any other expand/collapse relationship you may have in your particular environment. The set of actual "rules" is fairly minimal.

Do what makes sense, and always strive to be more effective in what you do.

Rate this Article

Adoption
Style

BT