I have been making the mistake creating branches at the User Story Level. See: User Stories != Features.

I believe I have been doing it this way because of my poor practice in organizing Features and Epics that are both permanent and really just organizational post to parent the underlying stories (EG. Improve Homepage\ As an advertiser, ...).

What is a better way to create Epics and Features?


Since I have been using Epics and Features to organize the backlog, my co-workers & I have, been using them to determine where to create User Stories. The problem with this, I believe, is rather than just having orphaned User Stories which I, as the designer, should be determining under which feature stories belong. This has created an phenomenon where User Stories get duplicated because the creator does not realize it already exists under a different "Feature".

So, Should I be requesting User Stories be created as orphans than afterward, determining under which feature they belong? Rather then letting product owners try to decide under what feature a story belongs.


An additional fear I have of this shift in planning, is developing based on User Stories moved fairly quickly, merging the Story branch back into the Main branch when completed, then deploying.

Can I still maintain quick deployments while working off a Feature branch instead of a Story branch, by merging with Main at the 'end' of each Story then continuing to the next Story in the Feature branch ?


Additionally, maybe a more direct and powerful method, an example in this case may provide more context than all the preceding answers.

Provide an actual example of a branch, and any Stories, Features, Tasks, Epic that it contained in your real world development projects.


Here is a mock diagram of my backlog

  • (E-#) Epic
    • (F-#) Feature
      • (S-#) Story | (B-#) BUG
        • (T-#) Task
  • (E-1) Sitewide Improvements
    • (F-2) CMS
      • (S-3) As a developer, I want to audit @inherits on cshtml pages, and see how I can better use Strongly Typing pages
      • (S-4) Upgrade to CMS Version 7.5.8
        • (T-5) backup
        • (T-6) Nuget upgrade
        • (T-7) run upgrader
        • (T-8) merge config files
  • (E-9) Improve Public facing site
    • (F-10) Improve Homepage
      • (S-11) As an advertiser, I want my ads to show on the homepage, so my ad have better visibility
    • (F-12) Improve Reviews
      • (S-13) As a traveler, I want to be able to sort reviews by # of stars, so I can look at reviews with the # I am interested in
        • (T-14) Create a sorting logic in a function to accomplish this
        • (T-15) Create the proper UX to request sorting
      • (S-16) As a traveler, I don't want to see old reviews, as they don't represent well
    • (F-17) Improve Articles Page
      • (S-18) As a reader, I want to articles tagged, so that I can view other articles with tags I am interested in.
  • (E-19) Improve Client backend portal site
    • (F-20) Account Management
      • (S-21) As a portal user, I want notification to be emailed to me, so that I know what is happening
    • (F-22) Ad Manager
      • (S-23) As an advertiser, I want to set budgets on a per advertisment basis, so that I can have greater control.
      • (S-24) As an advertiser, I want to be able to upload my on images, so that I can better customize my ads.
    • (F-25) Billing Manager
      • (S-26) As an portal admin, I want to be able to see past statements, so I can understand past charges.

1 Answer 1


It looks as though you're conflating several things that should stay apart.

First off: your branching strategy and your work-item breakdown structure do not need to match. The branching strategy should be used in support of communicating how you've gotten to the source code you have, but that need not have been by slavishly following the work-item breakdown.

Second: the user stories and features are not necessarily the granularity in which you deploy new versions. You may well need an entire epic or even multiple epics implemented before rolling a new version out to customers. That does not mean you need to keep a branch apart for the entire duration of implementing that epic; you may well want internal releases much more often, so you need to integrate regularly. This is helped by using e.g. feature toggles.

Third: the work-item breakdown structure is not the best repository for encoding the knowledge of what features have been implemented. It would be wise to e.g. keep a document in your source tree that describes all user stories that have been implemented. Keeping that document readable and well-organised is a part of your development work and helps answer the question of 'how does this user story fit in with the rest of the program?', which you also seem to struggle with. Note that it is not a bad thing at all to have the same user story in multiple work items; that just means that you see that that user story needs to function for multiple reasons. It may also be that the occurrences of the same user story are separated in time by months... in which case a document in your source tree is much preferable over the history of work items worked on. For extra kicks you could automate checking the user stories so that the document turns into living documentation.

Hope this clears up things a bit.

One thing of note is that you seem to mix abstraction levels in your product backlog; trying to keep the value in mind when writing the user stories helps avoiding that trap, and one way of doing that is popping the why stack. E.g. in the case of 'As a portal admin, I want to be able to see past statements, so I can understand past charges' you'd ask 'Why do I want to understand past charges?', and so on, until the value provided is crystal clear.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.