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

Closed. This question needs to be more focused. It is not currently accepting answers.

---

开发者_JS百科

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this 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.

---

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.

---

As you suggest, one way to approach this is to consider rejection from the outset. Requiring that every user story can be enabled or disabled through a configuration directive guarantees a releasable build without the rejected stories.

If you are really serious about excluding the rejected stories, a configuration directive is not enough because it can be edited by the client. You may consider compilation constants in that case.

This approach requires some additional code and testing, but saves you the hassle of branching and merging. You can also leave your revision control environment in place.

Hope this helps.

---

I agree with @DancesWithBamboo - you're asking about the symptom, not the real problem. The problem is:

Why is the PO rejecting the stories?

• Are the stories incomplete? If so, then they shouldn't have been committed to the release and the team needs to be reminded that there should be no "partly done" stories - done is yes/no.
• Do the stories not do what the PO expected? Then you need to spend more time in the pre-sprint meeting becoming very clear what the story means before the team commits to it. Also consider using automated acceptance tests with something like FitNesse. If the PO helps write the acceptance criteria then he/she will know what to expect when the story is done. See also "Card, Conversation, Confirmation".
• Did the business needs change during the course of the sprint? Then maybe you should shorten your sprint so that the PO can have the team abandon stories that are no longer needed.*

And are you doing Sprint Retrospectives?

Agile practitioners talk about "Inspect and Adapt" or "Plan-Do-Check-Act". At the end of the sprint, have the Team and the Scrum Master discuss what worked, what didn't, what you'd like to add. There are various styles of retrospectives - the important thing is that your retrospective should result in actionable items that are designed to improve your process. Agile doesn't mean keeping the process the same - there's always room for improvement.

(* Some people recommend that, once a sprint has started, there should not be a change to what stories are worked on. For me, this is too rigidly holding onto process. I don't see any sense in a team finishing a story if the PO has legitimately determined that it no longer provides business value.)

---

Take a look at one of the newer classes of distributed source control such as Mercurial. Code commits form a dependency chain making it easier to back out specific functionality without disrupting other parallel work.

Joel's HGInit tutorial explains Mercurial very well and does work through an example of parallel feature addition.

---

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

I think there are 2 aspects to your question. One is version control plus release management strategies, and the other is how to handle 'Undone' work.

As far as the version control part goes, your solution is simpler than you think. With svn each commit creates a tag for the whole project with a tag number. You can do an svn revert on just a particular User Story check in tag. A best practice article suggests that development should always be done on the trunk, and you should only branch for a release. So any unreleasable code should be reverted using svn revert on the tag number on the trunk, and then the release branch should be created. After the branch is created, you can check in the unreleased code back again and continue working on it on the next Sprint. Continue working on bugs or release issues on the branch itself without meddling with the trunk. Offcource do not forget to merge the release branch back to the trunk periodically.

And about the undone work goes, first of all it is a good thing that your organisation recognizes the difference between shippable and non shippable, so that is a good step. Secondly you need to investigate why work is left undone, try to facilitate some questions in the Retrospective which will help your Team avoid such situations, using the inspect and adapt principle.