Managing 'done' but not releasable code in TFS

Question

I am working in an organisation with 11 scrum teams developing on the same code base. Currently, all development is done in trunk, and at the end of a sprint everything MUST be releasable, or it must be backed out (an arduous process) as a release is cut.

My opinion is that while work in a sprint is (ideally) 'done' at the end of the sprint, this doesn't necessarily mean ready for release. You may be at a point where you do not have a Minimum Viable Product to release, but have some stories complete. If a story is not done, or the story is only part of a larger feature, it should be easy to keep this separate from the release ready code. At the moment it is all backed out, the release cut is taken, then it is checked back in. A huge waste of time!

We use continuous integration, which is the main argument for everyone developing on trunk. Occasionally teams use a team branch, but this is currently frowned upon.

I've been considering simply having a 'dev' and 'release' branch, and pushing features to release when they are an MVP, or having a branch for each story or feature, but this is very admin heavy in TFS. Have other people dealt with similar issues in the past, and what are your thoughts on the best way forward? Unfortunately, we are tied to TFS in the short term.

Answer 1

Looks like you are completely borked with that lack of branching. At the very least you should be developing on a Dev branch and merging completed code onto Main when your code is working and 'releasable'. This would stop the stupidity of reverting committed work if you failed to meet your deadline and re-committing it afterward. The days of using VSS are long gone!!

Every team should have their own dev branch, but I can understand if you all want to work on a single Dev branch.

CI should be applied to both Dev and Main branches, and extra analysis on Main too - we used to put some very long running static analysis, doc generation and testing on Main that would have slowed Dev down too much.

Microsoft recommends using a Main branch (or trunk) with Dev branches and Release branches in their TFS model. (the old docs are here, though they say they are outdated.. but neglect to link to their current views)

Answer 2

The scrum guide is very clear: The work of a sprint is to deliver a potentially releasable increment of 'done' product at the end of each sprint.

There are a number of reasons for this but the main one is to avoid incurring unnecessary technical debt. Until you have made your product potentially releasable, you do not know how much work remains to be done, or how long it will take to release.

It looks like you have an excellent branching policy in place and it's great to see that you are doing continuous integration. I wouldn't change a thing.

One issue I do see though, is where you describe a story as being part of a larger feature. I can understand why this would cause issue with your branching policy. But I think the problem is with your pbi. A good product backlog item should be independent and I'd be more inclined to look at improving that to resolve the problem, rather than compromising on branching.

Answer 3

What you could do is define epic stories with substories.
Create a branch for that epic story and then branch off that one for every substory. When each substory is done, merge its branch back to the epic story branch. When the epic is fully finished, you can merge that branch back to master and release everything.

I have to agree with Derek Davidson though; it sounds like you are building your features one part at a time, instead of incrementally (which sounds like the same thing, I know).
It reminds me of a picture I saw on Twitter about how Spotify does things. Instead of immediately building a car one wheel at a time, they went from building a skateboard, to a kick scooter, to a moped, ...
I'm aware this is easier said than done, but keep in mind that there's always a way, even if you can't see it right now. You could start by asking what the report is for and trying to reason what the absolute easiest, simplest way would be to fullfill that goal.
It could be something completely different than a report.