Re: CI != Code Review?
Except when the client or management say that it HAS to be patched up and out the door for the trade show or that there's no more money left and we have to go with what we've got (plus a little unpaid overtime).
Yes, every two weeks we re-evaluate everything we are doing to determine whether it is still worth doing more work to that for the business (not us). We tell the business how long it takes to deliver quality, so if we haven't got enough time to deliver quality, either we've been slow or we're bad at estimating.
Given we are only estimating tasks that take less than 2 weeks, you really can't be that far out. And if the feature you're working on was scored for "2 days work" (thats not how we score things), and it takes 10 and is still not done, then you either didn't get enough details from the project owner (hence his fault - the job of the project owner is to give well specified tasks to the team), or the task is overly complex and should be re-evaluated anyway.
Before you move to a scheme like this, you have to have buy-in from all the key stakeholders , so that when that trade show rolls around, you can easily say "No. This was not agreed on. If you want us to work on things, you have to present it through the project owner who will prioritize your requests alongside everyone elses.".
I've happily said this to C-level execs, they agreed this working model. This shifts the discussion about whether you do something away from your team; it's then a business decision, and they can horse-trade all they like in order to change what you do *next* sprint - no-one can change what you do *this* sprint.