Repeat this step for each work item type you want to change. You change the way cards appear on the Taskboard in the same way you change the appearance of cards on Kanban boards. Add or remove fields from cards on the Taskboard If you're new to working with these tools, see Sprint planning. Also, add fields with information that you can use to filter the board. Or, you can show fields based on updates when using the Taskboards. Your best bet is to show fields on cards based on what your team frequently refers to. Does your team like to refer to work items by their ID? Do they want to see estimates? Do they want to highlight work items according to set criteria? Or, will just the bare bones of title and assignment suffice? It all depends on what's of interest to your team. You can either increase or simplify the information that displays on your cards. Apply styling rule to display tasks with Priority=1 as green.Show all core fields: ID, Assigned To, Remaining Work, Tags.In the card shown below, the following customizations have been set for the task work item type (WIT): To make severity 1 bugs stand out, a styling rule has been added to cause the card to display as yellow. It also shows three other fields and tags. In this example, the bug work item type (WIT) shows all the core fields. In case you're not seeing the desired work items on your backlog or board, see Set up your backlogs and boards to configure them according to your preferences. Click on any to enlarge.For more information, see Backlogs, boards, and plans.

Here are some photos of actual task boards in use.

This column just contains a checkmark to indicate the tests are specified. Many teams find that it helps to have acceptance tests identified before coding begins on a particular story.

Tests specified: We like to do “Story Test-Driven Development,” or “Acceptance Test-Driven Development,” which means the tests are written before the story is coded.

Notes: Just a place to jot a note or two.

Optionally, we sometimes use the following columns on a Scrum task board, depending on the team, the culture, the project and other considerations: Sometimes we remove some or all during a sprint if there are a lot of cards. They're removed at the end of the sprint.

Done: Cards pile up over here when they're done.

321 in Bugzilla”) so those are placed in the “To Verify” column. Some task cards don't get corresponding test cards (“Fix Bug No. So, if there's a “Code the boojum class” card, there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the boojum,” “Write FitNesse fixture for the boojum,” etc.

To verify: A lot of tasks have corresponding test task cards.

Often, this happens during the daily scrum when someone says, “I'm going to work on the boojum today.” The programmer who chooses to work on it moves it over when she's ready to start the task.

Work in process: Any card being worked on goes here.

To do: Place for all cards that are not in the “Done” or “In Process” columns for the current sprint.

Story: The story description (“As a user we want to…”) shown on that row.

The columns we generally use on a taskboard are: Each task card starts on the Scrum taskboard in the “To Do” column. Each of these is represented by one task card that is placed on the Scrumboard. Each product backlog item is turned into multiple sprint backlog items. During the sprint planning meeting, the team selects the product backlog items they can complete during the coming sprint. As an example, the Scrumboard looks like this:Įach row on the Scrum board is a user story, which is the unit of work we encourage teams to use for their product backlog.

Victorian style model taskboard