This one has nothing to do with me, right?

Oh, that's really funny. You think I would have caught that, huh? Tks for the laugh. And no, it doesn't. -- Tim Ottinger

Actually, for it to be about you, Michael, it might have looked like this:

If you had all the Featherses you can carry, could you carry just one more Feathers?

I'd eat one of the chickens.

Sheesh. Do I have to explain everything?

What has it got in its pocketses?

Anyway, I think we can all agree that more Featherses would be a good thing.

Doesn't the answer depend upon what development model the teams are following? And whether there is a Project Management type framework in place as opposed to a sprint based scrum model?

I don't think it matters which style. People have finite capability either way. Agile desnt change that though an agile team should have a better handle on their capacity earlier in the process.

I think that agile makes us focus and work hard, and then exploits our velocity to empower planning and management. It then protects our velocity with "sustainable pace" edicts.

We may find we can "carry more feathers" than we thought we could, but ur capacity is still
finite.

Neither does a traditional project make us infinitely capable. It just grinds us down regardless. When expectations don't match actuals, waterfall always blames actuals and never adjusts the map to match the terrain.

It demands more than we can give. It is a poor manager indeed who asks his people to leap into the air and hover. A good manager plans to win, instead of planning on a miracle (a lapse in the laws of physics) to save him.

If it's a Michael Feathers then probably just the one.

I agree, regardless the model, teams have finite capacity and velocity. Yes, yes, yes - straight math if one chooses. However, I disagree that the model choice is innocuous .. and said choice changes the value of the question.

Calculating velocity and capacity per sprint using story points is a complete overhaul of the "completely identify all tasks for life, estimate them all, and then add 20% contingency model". In this model the team is constrained to the plan and many project managers do not like work to be done "out of order" or ahead of schedule .. but rather prefer order.

Constrastingly, using a sprint model with self-directed teams allows them to eat what makes sense, when it makes sense and changes the _value_ of what is worked and delivered. In essence, the fun question of "could you carry just one more.." is irrelevant me thinks. Who cares whether one can carry yet one more .. it's the wrong question IMO.

I agree that asking a team to carry just one more Feathers is the wrong question to ask. Instead they should be asking how to get the same (or greater) value for fewer Featherses.

The feathers analogy is cool, but I don't think it attacks the core problem. The core problem usually presents itself like this: someone promises something on an unrealistic schedule and they feel that they can't revisit it without jeopardizing their career.

Often the promises come from outside the project team. The case I'm particularly mentioning is a kind of institutionalized dishonesty. The team says "we can do 16 points <wink>." Management says "then we'll only give 16 points of stories to do <wink>" and the team takes on 16 story points and later receives 8 non-story tasks. And some of the stories are initially sold to the team as being smaller in order to get short estimates, and the customer brings out the real requirements when reviewing the "finished" work. It's a win/lose game where you get people to commit to a date, then you increase the scope on them. I don't see that as healthy. Better if we estimate honestly and commit honestly, don't you think? -- Tim Ottinger

I agree, I'm just getting back to motive. Either someone can't tell someone that they are going to be late, or someone is thinking "gee, if I push the team and get more done, I'll look good." -- Michael Feathers

Ultimately, I think that the fallacy is that pushing teams is a good idea. However that manifests, if the system begins with the idea that the team is a bunch of lazy so-and-sos who have to be coerced into doing work it tells you something about the people who are running the system. They don't respect you, they don't trust you. Then that makes you ask whose fault that is. Either way, it is clearly an indicator that the organization is unhealthy and divided against itself.