Great questions as always. Part of the value of MMFs is exactly that they can vary in size. Then it follows that you can use story count as a measure of size.

Now, given the chance, I prefer using a method like QFD for requirements definition. However not everybody is up to that level, so MMFs and stories are a reasonable backup method for existing Agile or other medium-capability teams.

I exploit this short post to write another question, I hope you don’t mind it.
It’s a while I’m wondering if a Project Manager, to be considered a real project manager, must have a degree or a sort of certification.
I’m not just talking under a company point of view, I can understand that in that case a degree or certification would be much better. Instead I’d like to know if you think that an accademic background makes the difference or “on-field” experience and strong leadership as well as many other necessary skills are enough to be a succesful and effective PM (expecially for the agile PM).

it’s a long time I want to ask you something about MMF.
It looks like there isn’t a standard definition of MMF, expect the one that one can find in the software by numbers book that I haven’t read yet.
You write: MMFs are business-valued. User stories are merely user-valued.
And it looks like that in your case you use feature crew MMF that you split into user stories (maybe developed by one member only?) and you don’t use tasks. This is a vision that I actually share with you.
Some people though say that MMF are actually user stories, like here: http://aaron.sanders.name/agil.....-the-small .
Now let’s say that one uses the method he likes most, that in your case, if I got correctly, you use MMF split into user stories. In this case you told me that is better to try to create equal-size stories, if this is possible, is it possible to estimate the MMF size in terms of number of user stories or you think even the MMF must be equal sized?
About the branching, I agree with Brad, I think it’s better to branch by user stories, at least this is what I have done succesfully so far, even if I can understand your point of view.
Thanks for your replies

I don’t think this design represents pull very clearly. My next big article will have some enhancements to this kind of system that should improve feature cohesion and flow and reduce information loss.

This is a great post. We were employing this concept (sans the Kanban board) a few years ago when I worked at CheckFree. Most large customers I work with a V1 are dealing with this kind of complex product development. David Laribee just turned me on to this post. Nice explanation of the concept… thanks!

Mike

The point about estimation is not to do it or avoid it for moral reasons, it’s about cost and value. Estimation can have high cost and low value. We want to make it cheaper and the cheapest estimation of all is no estimation. A histogram of cycle times will tell you how much effort is worth investing in estimation. Some people do estimate with kanban systems, and you can limit something like function points instead of cards. My first suggestion would be to very quickly triage work items into two categories when they show up in the design queue: too-big / not-too-big. Not-too-big items go forward. Too-big items are requeued for further analysis. You can reduce the number of too-big work requests by making QA part of the analysis process. Right-sizing features is a matter of analysis skill and it can be learned.