Something to keep in mind:

Equally important and helpful as naming and using an assortment of columns is the entry and exit criteria for each column. For example our team has the following:

An item can enter the Sprint Backlog if...

1. it's Independent from other work items (not blocked)
2. it's Negotiable with product owner (business value has been evaluated/understood)
3. it's Valuable (it's been prioritized based on value delivered)
4. it's Estimated (the card has been broken down to <= 13 points of effort)
5. it's Small (can be forecasted to fit a sprint)
6. it's Testable (a test approach has been agreed upon)

An item can exit Development if it has...

1. Appropriate unit test coverage?
2. Appropriate automated acceptance test coverage?
3. Appropriate level of platform (Browser/mobile device) test coverage?
4. A successful build, deploy, and manual test coverage via release pipeline?
5. Appropriate localization/globalization?
6. Passing automation tests?
7. A test strategy that is completely documented?
8. Acceptable functionality based on acceptance criteria?
9. Browser compatibility with IE, Firefox, Chrome, and Edge?
10. Peer review from the team?

An item can exit Review if...

1. Product Owner has used the functionality in QA and has acknowledged acceptance criteria has been met.

Notice our team only really uses three columns, but denoting criteria for each really helps everyone understand what needs to happen in order for work to flow through the board and why it needs to happen. If you're using Scrum, think of this criteria as your definition of ready and definition of done. The above is simply an example and may not be 100% appropriate for you to use. Hopefully, though, it gives you some ideas and helps your team really understand what each column really symbolizes, however you choose to define them.

Something to keep in mind:

Equally important and helpful as naming and using an assortment of columns is the entry and exit criteria for each column. For example our team has the following:

An item can enter the Sprint Backlog if...

1. it's Independent from other work items (not blocked)
2. it's Negotiable with product owner (business value has been evaluated/understood)
3. it's Valuable (it's been prioritized based on value delivered)
4. it's Estimated (the card has been broken down to <= 13 points of effort)
5. it's Small (can be forecasted to fit a sprint)
6. it's Testable (a test approach has been agreed upon)

An item can exit Development if it has...

1. Appropriate unit test coverage?
2. Appropriate automated acceptance test coverage?
3. Appropriate level of platform (Browser/mobile device) test coverage?
4. A successful build, deploy, and manual test coverage via release pipeline?
5. Appropriate localization/globalization?
6. Passing automation tests?
7. A test strategy that is completely documented?
8. Acceptable functionality based on acceptance criteria?
9. Browser compatibility with IE, Firefox, Chrome, and Edge?
10. Peer review from the team?

An item can exit Review if...

1. Product Owner has used the functionality in QA and has acknowledged acceptance criteria has been met.

Notice our team only really uses three columns, but denoting criteria for each really helps everyone understand what needs to happen in order for work to flow through the board and why it needs to happen. If you're using Scrum, think of this criteria as your definition of ready and definition of done. The above is simply an example and may not be 100% appropriate for you to use. Hopefully, though, it gives you some ideas and helps your team really understand what each column really symbolizes, however you choose to define them. If it's not working, you can always revaluate, add columns, remove columns, and collaboratively redefine their criteria to fit your team's needs.