Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

What about changed source when a PBI is not Done?
Last Post 01 Apr 2014 12:28 AM by Ludwig Harsch. 2 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Franck van der Sluijs
New Member
New Member
Posts:22
Franck van der Sluijs

--
27 Mar 2014 02:00 PM
    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?
    Chee-Hong Hsia
    New Member
    New Member
    Posts:73
    Chee-Hong Hsia

    --
    28 Mar 2014 01:01 AM
    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

    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    01 Apr 2014 12:28 AM
    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
    You are not authorized to post a reply.


    Feedback