What should be the attitude towards getting stories done that are assigned to a sprint? Obviously you want to prioritize getting them done in the sprint, but to me the whole point of agile is to be dynamic: You don't want to deliberately procrastinate or make it "ok" to miss finishing user stories in a sprint, but at the same time when unexpected things come up, and those stories do not get completed and are pushed to the next sprint, you don't want the feeling that you did something wrong. That shouldn't be a scary or negative experience, should it?
Are negative/scary experiences acceptable for missed sprint commitments? Should developers be held accountable for missed sprint commitments when unexpected tasks come up that must be dealt with (Eg. production support)?
Best Answer
You should absolutely aim to get items done within a sprint.
One of the main benefits of SCRUM is that it gives the project a 'heartbeat'.
You prioritise, pick items off a list, you deliver them, you demo them, you reflect how they went, then you do it again in preditable cycles.
All of the planning, estimations and prioritisation are based off of this concept. That we can and will commit do X points within the sprint, and can, over time, establish a velocity from that we can use for better planning.
If you are too casual over the content and commitments of your sprints then SCRUM just breaks down in my opinion and you lose a lot it's benefits.
Of course the real world will sometimes have something to say about this, but that should be the exception rather than the rule....