Take the 2-minute tour ×

I'm running a team of 4 developers and 2 testers and trying to abide by the Scrum principle of creating a PSP with every sprint. That means I need to create a potential release with all the user stories that got to Done and store it on some publish server for the PO to do with as they please.

My problem is how to technically create the build when some stories are not at Done at the end of the sprint? The code is checked in, but didn't completely pass testing.

If I only check-in code that is Done, i.e. code complete-reviewed-tested, I run in to the possibility of diverging code bases and merges that may be disastrous. For instance Developers A and B work on different features that modify assembly X. Dev A finishes coding, pushes assembly X to test. The next day Dev B finishes coding and pushes assembly X to test. Feature A comes back with bugs, feature B is perfect. Oops, sprint is over. Now, how do I create a PSP with feature B but not A?

share|improve this question
merges that may be disastrous I'm battling one right now... –  Yannis Rizos Dec 20 '11 at 9:47
add comment

4 Answers

up vote 2 down vote accepted

The key is:

  • clean and well organized code
  • good source control (probably distributed) supporting branching and automated merging
  • automated test suite
  • continuous integration which can grow to continuous delivery

You can either:

  • Create everything in trunk and revert all incomplete stories (after branching) from the trunk. This can have significant impact on the code base especially if stories required big changes to shared code.
  • Use branch for each new story and merge it only when the story is done. It has one significant problem. The story is tested in isolation and the feedback is collected to slowly but imho this is the easiest practice. Big helpers are good tools and good code / tests.
  • Develop all user stories in trunk and keep shippable product in branch. It solves to problem with isolation but it has high demands on merging strategy which can be very hard in case of changes to shared code.
  • Combination. Keep the shippable product in the trunk and stories development in branches. Merge all commits between branches and trunk (every branch must always have the latest committed code from others). Make sure that new features in trunk will be available to end user only after the whole story is completed.

In the last option you will ship incomplete stories but they will not be available to user - only their code will exist in your code base. The requirement is that all other users stories must be working.

I have also used much simpler (but not Scrum like solution). We didn't removed incomplete stories if they didn't break the completed stories. We just said on review meeting that we were not able to complete these stories and that they should not be used because they don't work. This option is possible only in case of internal releases where end user just validates completed stories and is not going to use the product for the real work immediately after the sprint.

share|improve this answer
We left the incomplete features in the code but removed them from the UI. In most cases this could be done by removing a single line of code (or configuration script). This was done for internal or limited releases (as in no more then 20 installations). In production releases all not completed features were removed (usually we had 1 or 2 polishing sprints before a production release). –  refro Dec 20 '11 at 14:51
We ended up doing something very similar. Every build that is passed to QA is a PSP and receives it's own branch and label (this is done automatically with a small deployment app + teamcity configuration). This happens several times a sprint (for almost every story/a bunch of small stories) so that by the end of it if something passed QA - there's a shippable branch for it. –  Ninjarabbi Oct 11 '12 at 16:09
add comment

The root issue here is stories not done at the end of the sprint. That is the problem you should try to solve.

In other words, ask the team "how can we finish all my stories by the end of the sprint?" not "how can we adapt our process to manage my half-completed stories".

share|improve this answer
Well that's a bit unrealistic, isn't it? Obviously we aspire to it, but sometimes something appears to be simpler at planning than it actually is. Shit happens and we need to live with it, isn't that the whole point of Agile? –  Ninjarabbi Dec 20 '11 at 15:52
It is not unrealistic. Shit happens but if it happens every sprint something is wrong with your estimation, planning, velocity, etc. –  Ladislav Mrnka Dec 20 '11 at 16:41
Shit happens and we need to live with it, isn't that the whole point of Agile? Wow, is this what people think nowadays? –  xsace Dec 20 '11 at 17:20
Yeah, Agile for me is having a flexible mindset for dealing with mishaps instead of trying to plan them out of existence. In other words, it's cheaper to know how to deal with changes than to try to predict and plan for them all. –  Ninjarabbi Dec 21 '11 at 18:11
Capture metrics on how many incomplete story points remain on average per sprint. Decrease the workload on the next sprint by this number. –  Cliff Dec 22 '11 at 8:41
add comment

The key is to not allow code to "break the build". In other words do not check in code that doesn't pass testing. If you run a nightly automated build/test cycle this should all be automated for you.

Code which fails would still be stored in the repository as a branch, it would just not be part of the PSP.

In particular you should make use of continuous integration practices and a source code control system like Mercurial (KILN) that are designed to support this.

share|improve this answer
add comment


Assuming Feature A stories have unit/acceptance/integration tests.

Developer B check in his code in a staging area.. if all tests pass, including the one for Feature A, Feature B code gets automatically merged to production..

you can do above with Distributed Version Control

share|improve this answer
add comment

Your Answer


