BT

The Further Value of Collapse

by Liz Keogh on Mar 03, 2011 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Thanks by Mike Burrows

Thanks Liz. I did find both angles interesting, and though I remain comfortable with my (then) teams' current practice (which is not to collapse explicitly) it's good to be open to alternatives. It definitely helps to see it from both sides and to understand when it would be most valuable.

One small correction (or a shameless plug) - as of March 1st I'm now an independent consultant. I'm still working with the teams I referred to in that thread but I have other clients too now.

Mike

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT