About the sprint immutability about agilelite HOT 4 CLOSED

How I see it:

• Only remove, no add, is a good idea. For what is part of the sprint: what we commit to
• If you need to “swap” something in, it can only be put into next sprint. (footnote1)
• Nothing will stop people from finishing work early then starting on future work such as work in the next sprint. But it is not committed-to.

(footnote1) ... unless it is a small issue which fits in the limited capacity for Support Issues, see recent discussion on #4

The big problem with allowing swaps is that the swapped-in items are rarely properly estimated. Some cognitive biases play into it, surely...

... And over time I’ve seen this result in not taking planning seriously, because people see they can always swap things

from agilelite.

From what I understand how it is defined in scrum.

Changing element in a sprint means something was wrong for various reasons so when you will debrief your sprint, you have to understand why it happened and how not to have the same situation next time, it's where the feedback loop come.

What I saw several times was people stucked in a situation where they had to change something in the sprint but they did not because you have this kind of belief everything is defined once. So they reached a kind of non-sense situation instead of being agile and moving forward.

Most of the time, you don't have to do this, but from time to time you have to, so you have to recognize those moments and act properly.

If someone is doing this abusively, someone as the scrum master (sorry I speak in term of scrum but I have no other references) must explain again the whole process and provide with the dev team an help to such a kind of person to better plan his/her job.

from agilelite.

Couple thoughts I had reading through this:

Conceivably this is a system that could be used at different types of companies. Are you a product company building a product and selling it to customers? Are you a consulting company where you have clients with goals and expectations and you have to allocate your internal resources to bring those to fruition? Are you a team of 5 people making a game? Or maybe an organization geared towards cutting edge machine learning research? All of these examples will have slightly different circumstances/situations/needs/etc. and their sprints might look different.

That being said, am I crazy for thinking that a lot of stress in writing code for money comes from the client/boss/manager/drum-beater/whatever saying something like "Hey, we just had this thing come up, can you give me an estimate on that and see if you can fit it into the current sprint?" I've had this happen as a developer and I've had this happen as a manager and in both scenarios I think the solution is to default to "we can't change the list of things to do and if you need a new estimate you're taking me off from something i was already doing and therefore losing out on my productivity for the day".

Maybe it's just the way I work or handle information, but this scenario has been so common in my experience that I think "don't add new tasks to sprints" is a pretty good rule to default to. If something can't wait (and it often can't) then fair enough, hence the discussion here re: support and so on. But even those support issues end up being a productivity suck. Or is it really just me?

from agilelite.

It's not just you!

My 2c: I am in favor of "no new work added to sprint" (Support Issues being a special case but it's not new work; it should just be the definition of issues filling up already-allocated Support time). I am in favor of this as a rule, even though it will be broken — because it should be recognized as breaking the rules when this happens.

from agilelite.