What about changed source when a PBI is not Done?
We are using TFS. We use a Dev branch and we merge to the Main branch after each sprint.
When a PBI is not Done at the end of a sprint, the PBI will be put back on the Product Backlog. But what about changed source code? The source code must be in a potential releasable state at the end of the sprint.
Do we need to rollback all changes for the unfinished PBI? And to continue in a next sprint we have to save the changes in a shelfset? That will be hard when there are Done PBI’s in the same sprint. And there is a risk of breaking working code.
Sometimes it’s possible to ‘disable’ a new feature when it’s not Done, but in many cases that’s not possible.
Do we need to use a separate branch for every PBI to handle this? Or are there other solutions?
We use the Gitflow methodology to manage our items.
What we usually do is every item that the team is working on are individual “feature branches”. Somewhere at the end of the sprint the team creates a so-called “Review Branch” where all feature-branch items are added in.
This Review-Branch will be deleted after the Sprint Review but it does give the team great inside of what can go further (Develop Branch) and what needs to stay in its Feature Branch.
Cheers, Chee-Hong
Hi Franck,
the source code doesn't need to be in a potential releasable state at the end of the sprint. Instead you have to deliver a potentially shippable increment. If you define a specific tag on your main branch as the increment, than this one should be in a potential releasable state. So if you merge something into this branch just before the end of sprint, but it doesn't fulfill the definition of done (e.g. tests fail), you cannot tag this version as the increment but you have to use an older one where the DoD was fulfilled. To mitigate the risk of not having any increment, you should merge as often as possible, not only at the end of each sprint.
Best, Ludwig