[lostcolony]

So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story), and can turn them into time measurements them however they like if they want to; we're not committing to their estimate.

All we're committing to is to deliver what -we- choose to include in a sprint, will be delivered by the end of the sprint. We will choose what is in the sprint based on the prioritized backlog. How they prioritize those things doesn't actually matter to us. They think that 8 point story we pulled in is going to take us two days? Doesn't matter. They think that 8 point story we pulled in is going to take us two weeks? Doesn't matter. They're not the ones deciding how much we can take on in the sprint, nor are they the ones committing to get it done. All we are telling them by our pulling it in is that it will be done by the end of the sprint. And that's what I meant by management has to change; that reality has to be acceptable to them, that getting relative points, to tell them the approximate amount of work (or t-shirt sizes, or whatever) relative to other stories is all we can really tell them, and that we will pull in the prioritized stories based on what we think we can get done. If they don't trust us to do that, and want to micromanage, then -no- development methodology is going to help you, not agile, not waterfall, not -anything-, because you have systemic dysfunctionality.

[jackmaney]

> So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story)

First, they'll ask how much longer ~that~ task will take to complete than ~this~ task. Then, they'll ask how long ~this~ task will take to complete. Then, they'll use this little trick called "math"[1].

> and can estimate them however they like if they want to; we're not committing to their estimate

Well, guess what? If you refuse to give deadlines, then they'll be established for you. I don't know about you, but I'd rather have a say in my deadlines (where possible).

[1]: http://dilbert.com/strip/2002-05-19

[lostcolony]

Your experience dictates those things.

Mine does not.

You claim my experience can not exist.

I claim my experience can.

You also seem to ignore what I'm saying; we give deadlines. The end of the sprint. Whatever we take on will be done at the end of the sprint; they have control over what we take on by the backlog. Beyond that, we refuse to give any commitment (instead just giving relative weights to how long a task will take, to help in prioritization), and we are sufficiently empowered to not care if they try to commit us to something despite that. But they usually don't (the only time it's ever more immediate is "a bug was seen in prod and I want to know what caused it!", in which case that becomes our first priority task; again, because we consciously choose to undercommit ourselves, there is slack for that sort of thing to occur without delaying the schdule), because we work with them, listen to them, advise them, and they see that we are trying to help them do what is best for them, without causing a bunch of tensions and clusterf*ery. And because we undercommit we usually deliver more than we commit to, with time used to make sure things are reliable, so they have come to trust us.

In short, I hear a bunch of presumptions from you about what management -always will do-, whereas I know this from experience to be false. Management -can- adapt to viewing things along sprint boundaries. At least, mine has. Perhaps your problem isn't that a process is bad, but that your managers insist on micromanaging you and that you're not sufficiently empowered to push back?

[jackmaney]

> You claim my experience can not exist.

I have done no such thing.

Obvious troll has become quite obvious.