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

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.

  • How do you deal with Continuous Integration best practices if the code is not placed into the main branch daily? – GuyR Sep 28 '11 at 21:14
  • Nothing says you can't have multiple continuous integration instances running. What I'm suggesting is a bit of a paradigm shift. You should be pulling changes into your local repository (integrating locally) often -- you just aren't pushing your changes to the release branch until they are ready. It's up to your team to define what "ready" means. Maybe it's smaller than a feature, maybe it's only complete features. The important thing is that with DVCS you have the flexibility to choose. – Michael Sep 29 '11 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.