During the sprint review the product owner may say that a particular story is incomplete or the team itself may not have completed some committed tasks.
In what situations do you leave the code in the build? If the code is left in the build, is this a conscious decision made during the review? In other words, do you discuss this issue during the review?
Are there specific instances where code should be removed?
An incomplete feature should come out. But if this can be done without removing the code (feature flags, just removing the wiring, etc.) then that's fine -- preferable, in fact. Why? Because it limits the changes to a product which is already mostly-tested.
I would recommend that, if a story is medium-to-high risk, developers should always code with its possible removal in mind and make sure that task is as risk-free as possible.
Do what makes sense.
If the code isn't going to cause any problems (say it's a function that can't be called), and/or if you are going to finish the story next sprint, then taking it out's just kinda wasting time pulling it out in order to put it back in.
If, on the other hand, the code is destabilizing something else, or is user-visible in a way that doesn't work, or it has the potential to break things, and you aren't getting back to the story right away, then removing it is probably the right thing to do.
If the code that is there already has sufficient test coverage (unit tests etc), then you can keep it as it will still be being tested. If you have not got much automated testing going on, then you should probably remove it as unused code will rot, and the state of it will only be known later when it is again used. Unused, untested code is mostly noise.
Dead code, code that is not used, should always be removed unless it's going to be used in the near future.
Incomplete Stories
Just because a story is incomplete doesn't mean there is not value in running what you have. If there isn't any value in it then I think it qualifies as dead code.
The code for that feature never should have gone in to the release-ready codebase in the first place. This used to be pretty tough with server-based version control (e.g. SVN) if you weren't using feature branching. Nowadays with distributed version control (e.g. Mercurial, git) it's an easy thing to do.
In addition to tools, you may need to make process changes. For example, requiring that code be reviewed before it's merged, ensuring that the review with the product manager happens early enough in the iteration so that incomplete things can be course corrected and tested.
Bottom line is that you can't earn value on a partially completed story. Plus if it's not finished, the customer may change course with the next iteration in which case you have now caused bloat with a half finished feature.
