Like committing to a sprint target. And literally doing everything to fulfill it. Like not waiting for a manager to step in and ask for overtime and weekend shifts. Remember? Scrum teams take all the necessary steps themselves. Always! Isn't the entire point of scrum to enforce a sustainable pace of development? One that doesn't require heroics like having programmers come in on nights and weekends to finish? The ent…
Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint. This has partially to do with not over committing at the beginning, but if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises. Unfortunately, this clear obligation gets forgotten to often – as I pointed out in the original post. You seem to…
No. Scrum is explicitly open to renegotiation. This is where burn-down charts come in to play. This is where having the product-owner be part of the team comes into play. If a feature is costing a lot more hours than anticipated due to unforeseen problems, it is expected that the team gets the product owner involved early so that a decision can be made: do we drop other work to deliver this feature, or do we drop other features to deliver this?
The core premise of scrum and other agile methodologies is that given the uncertainties inherent in software development, it is impossible to fix both the featureset and the schedule. Scrum fixes the schedule and explicitly allows for flexibility in the featureset. Other methodologies (like spiral, for example) fix the featureset and allow for flexibility in the schedule. Waterfall attempts to fix both, and fails as a methodology.