Seems very reasonable. We are using something very similar. My advise is just to keep the feature branches small. Maybe one days work. Longer brances means lower productivity due to a large number of merge conflicts. Mostly one feature branch equals one post it note on our scrum board.
One note is you write "I start working on some feature. I create a feature branch off from dev." This is a good approach 80% of the times. Remember you have the option to branch of a pending pull request. We have a rule on the team that we should get someone else from the team to review and merge pull requests. Sometimes PRs stay in the queue for a few hours. Since we are using quite small pull requests. Sometimes feature B depends on feature A, but feature A is not going to be merged for a few hours and thus not in dev. When you want to start working on feature B just merge off of A instead of dev. It is better to merge off dev if possible, but it is a good tool in your belt. You should in that case probably wait to create the PR for feature B before feature A is merged to dev because diffs will look like both A+B which is misleading.