How do you make sure that you always have a releasable build? [closed]

Question

How do you make sure that you always have a releasable build?

I'm on a Scrum team that is running into the following problem: At the end of the Sprint, the team presents its finished user stories to the Product Owner. The PO will typically accept several user stories but reject one or two. At this point, the team no longer has a releasable build because the build consists of both the releasable stories and the unreleasable stories and there is no simple way to tear out the unreleasable stories. In addition, we do not want to just delete the code associated with the unreleasable stories because typically we just need to add a few bug fixes.

How should we solve this problem? My guess is that there is some way to branch the build in such a way that either (a) each user story is on its own branch and the user story branches can be merged or (b) there is a way of annotating the code associated with each user story and creating a build that only has the working user story. But I don't know how to do either (a) or (b). I'm also open to the possibility that there are much easier solutions.

I want to stress that the problem is not that the build is broken. The build is not broken -- there are just some user stories in the build that cannot be released.

We are currently using svn but are willing to switch to another source control system if this would solve the problem.

In addition to answers, I'm also interested in any books or references which address this question.

Answer 1

I think your desire to back out incomplete code is a band-aid on the real problem. The real problem to address is what are you doing wrong that gets you to the end of the sprint with unacceptable stories.

Sounds to me like you have one (or all) of 3 problems.

1. Incomplete Conditions of Acceptance, you apparently don't understand what the PO expects for your stories to be Done and accepted by him. You need to do more work in sprint planning (or before) to come to an understanding of what Done for each story is.

2. Not involving the PO enough during the sprint. The demo shouldn't be the first time he has seen the stories completed. It is just a final ceremony to close out the sprint. The PO should have been accepting stories all throughout the sprint.

3. Overcommitment; if you are coding to the last minute then you don't have time time to fully integrate and test. I'm not sure if you meant "bug" as in broken-not-tested-code or didn't-work-like-PO-wanted-code.

Branch per feature is an expensive thing to do for small teams and is more appropriate when building large systems with many scrum teams building component parts. It's like buying auto insurance because you crash a lot; it doesn't get you there faster it just makes you pay more along the way.

Try this for a sprint or 2: don't start on another story until the PO has approved the current one.