Starting branch names with b/ is a bit strange, since you already know that it's a branch, right? I'd decide for a branching strategy first and then base the names on that.
We usually follow git-flow, so we have develop for integration, feature/XXXX for feature development and bug fixing, release/XXXX for QA and release-preparation work, master for productive code and hotfix/XXXX for hotfixes.
As for the individual name part (XXXX in the above naming convention), we usually work with Jira, so we have an issue ID and then a very short description. For example, one of our branches might be called feature/PROJECT-1234-implement-back-to-top. That way, we can even track branches in Jira.
Other than git-flow, there is for example master-centric development, which makes master the integration branch and whenever you release code, you branch off into a release/VERSION branch for every version. The feature branches usually are the issue-id plus a short description. This allows for better support of multiple versions, however means that you have additional burden per released version. From the top of my head, Amethyst uses such a branching strategy for their game engine, which allows them to offer and support several versions in parallel.