At first, our board was simply divided into three columns: To Do, Doing and Done. We used to fill the To Do column at the start of a sprint with stickies containing User Stories and accompanying tasks. The tasks were defined during the sprint planning. Later we found it easier and quicker to define the tasks while in front of our physical board rather than in the meeting room.
We quit estimating tasks long ago. Our stories are small enough to be able to see progress during the sprint. Our progress is drawn on a burn down chart. Most of our user stories are around three story points in size. We do about fifteen of them during our two week sprints. Usually one or two stories will be finished per day.
We had a Review column for a while. Stories in that column had to be reviewed by the Product Owner before they could be marked as "Done". We introduced this column because too often our Product Owner would not be satisfied with a story during the Sprint Review. The Review column forced us to evaluate a story with the PO much sooner. Eventually, the quality of our work rose and we decided we could do without this column.
We added a To Deliver column to make visible which stories are ready for delivery to a test or production environment. Recently we upgraded our Definition of Done, and now every story has to be delivered to a test environment to be considered "Done", creating a continuous delivery flow.
The testing task can and should start before the development of a story is complete. However, it made sense to our team to have a Test column. A story in that column is delivered to our development environment and is ready to be tested by whomever is available at that moment to perform the testing task.
The most recent addition to our board is the Prepared column. Stories in this column have been are OK-ed by both the team and our customer. These stories have an estimate and are ready to be developed. We don't plan a sprint in advance anymore. Instead we pull the top Prepared item from the backlog as soon as we finish an item. In effect, this makes our process currently more Kanban than Scrum.
Every column on our board has a maximum number of allowed stories, another Kanban influence. This forces team members to focus on finishing work, rather than starting new work, and it promotes collaborating on items to get them done.
And there you have it, the current state of our board!