Power of No
Agile often relies on negotiation between customer and development. This negotiation means agreement of planned work, changes and requests during iteration.
For example, you have Sprint planning in Scrum during which Product Owner presents stories that he would like to have finished in the first place. However, that’s the team who does a commitment for given iteration and there should be possibility of saying
You should give a good reason of discarding work (some example can be: not enough resource, story not clear enough, too much work, etc.). When you would like to drop stories from iteration, there will be some discussion between customer and team, for sure. Customer always wants to have done as much as it’s possible, development team does not want to do be overworked. Personally, I prefer take less work and finish all of them rather saying that everything will be done and finally not much will be completed in the last iteration’s day.
Another situation when you can say NO is the changes in iteration. Iteration’s priorities can be changed when work has begun. You need to be aware of the impact of changes. If request disrupt current work, say: NO together with the reason (i.e. adding this would cause in not finishing some story).
These two cases present the usage of NO. But what if customer says:
Well, it does not seem to be a healthy situation in agile project. Agile is about feedback, shipping often, collaboration, following customer requests, working together towards common goal. I think that sentence below is the nice conclusion of NO's impossibility:
For example, you have Sprint planning in Scrum during which Product Owner presents stories that he would like to have finished in the first place. However, that’s the team who does a commitment for given iteration and there should be possibility of saying
No, we can't commit that this story will be done.
You should give a good reason of discarding work (some example can be: not enough resource, story not clear enough, too much work, etc.). When you would like to drop stories from iteration, there will be some discussion between customer and team, for sure. Customer always wants to have done as much as it’s possible, development team does not want to do be overworked. Personally, I prefer take less work and finish all of them rather saying that everything will be done and finally not much will be completed in the last iteration’s day.
Another situation when you can say NO is the changes in iteration. Iteration’s priorities can be changed when work has begun. You need to be aware of the impact of changes. If request disrupt current work, say: NO together with the reason (i.e. adding this would cause in not finishing some story).
These two cases present the usage of NO. But what if customer says:
We are paying you, you should do what we are asking for.
Well, it does not seem to be a healthy situation in agile project. Agile is about feedback, shipping often, collaboration, following customer requests, working together towards common goal. I think that sentence below is the nice conclusion of NO's impossibility:
If you can't say No, your Yes won't mean anything.
Etykiety:
agile
I like your point of view very much...
"If you can't say No, your Yes won't mean anything." - this is great, I love it! :)
Another great post Tomek, well done!
Instead of saying no you could also give them the option of reprioritising - so if you want x in the iteration then x has to be deprioritised or if you want to add x it is actually another story and will have to be prioritised against all your other cards...but I know of course everything is a must have ;) I very much agree to only taking points based on yesterdays weather