Skip to main content
added 135 characters in body
Source Link
Batavia
  • 460
  • 3
  • 8

We use featurebranches a lot. A feature in this context would be the delta that would result in a shipable product. A PBI might be a feature, sometimes a few PBI's together if it really doesn't make sense to ship one of them without the other. (for example it doesn't make sense to view a tax report without being able to enter the relevant information and the other way around)

Examples of this would be a new feature to your product (hence the game). A new screen, a new export template, a new button in the screen (including functionality behind the button of course).

The decision to actually go to production would be up to the product owner (in scrum) or agreements you made with the customer. But master would always contain work that could go to production if asked to do so. And a featurebranch should be the least amount of work to get your code into that state again.

We use featurebranches a lot. A feature in this context would be the delta that would result in a shipable product. A PBI might be a feature, sometimes a few PBI's together if it really doesn't make sense to ship one of them without the other.

Examples of this would be a new feature to your product (hence the game). A new screen, a new export template, a new button in the screen (including functionality behind the button of course).

The decision to actually go to production would be up to the product owner (in scrum) or agreements you made with the customer. But master would always contain work that could go to production if asked to do so. And a featurebranch should be the least amount of work to get your code into that state again.

We use featurebranches a lot. A feature in this context would be the delta that would result in a shipable product. A PBI might be a feature, sometimes a few PBI's together if it really doesn't make sense to ship one of them without the other. (for example it doesn't make sense to view a tax report without being able to enter the relevant information and the other way around)

Examples of this would be a new feature to your product (hence the game). A new screen, a new export template, a new button in the screen (including functionality behind the button of course).

The decision to actually go to production would be up to the product owner (in scrum) or agreements you made with the customer. But master would always contain work that could go to production if asked to do so. And a featurebranch should be the least amount of work to get your code into that state again.

Source Link
Batavia
  • 460
  • 3
  • 8

We use featurebranches a lot. A feature in this context would be the delta that would result in a shipable product. A PBI might be a feature, sometimes a few PBI's together if it really doesn't make sense to ship one of them without the other.

Examples of this would be a new feature to your product (hence the game). A new screen, a new export template, a new button in the screen (including functionality behind the button of course).

The decision to actually go to production would be up to the product owner (in scrum) or agreements you made with the customer. But master would always contain work that could go to production if asked to do so. And a featurebranch should be the least amount of work to get your code into that state again.