We are using Visual Studio Team Services (VSTS) which have epics, features, stories and down to tasks. We will also follow git dmz flow in which development happens in feature branches. We want to use VSTS structure but not breaking the principles and benefits of git dmz flow.
I was thinking of having a feature branch that will be branched out to story branch and story branch that will be branch out to task branch (where the actual dev work happens). Is this not add too much overhead for the dev team? Can automation help in this?
I am considering to use story branches like feature branches (in git dmz flow context) wherein, when a story is done, you can make a PR going to dmz branch (but it kind of destroys the structure in VSTS/agile structure?)
I believed that tasks can be finished not more than a day so task branches should be short-lived. I also assume that features take days to complete.
It seems you have bundled the work items and branches together.
In Git DMZ Flow, it talks about how to use different branches to build/release your projects efficiently. And this article has no business with WIT (work item type).
On the other hand, branches and work items usually is not one-to-one correspondence but one-to-many relationship. That means what you prepare to develop on feature branch can be listed by detail operations in work items.
For example, there has a feature branch which need to export reports for a company, let call the branch name is feature/reporting here. Now you can list detail works for this feature in work items as:
|___ daily report (User story)
| |___ template design (task)
| |___ function develop (task)
| |___ QA test (task)
|___ monthly report (User story)
| |___ … (task)
|___ yearly report (User story)
|___ … (task)