Call it your story wall, call it your agile board, call it your scrum wall, call it what you like. I call it a task board, and I like to keep it simple.
If you’re in a situation where you can have a physical task board, then you’re winning. Feel free to do stuff electronically in Jira or whatever, because that’s probably how you do things, but beware that anything you do electronically not only duplicates what you do on the board, it also tends to suck you into doing things in a tool that would be more effective face-to-face.
Make your physical task board the one source of truth, and consider everything else supplementary, optional and secondary.
Do a Google image search for scrum task board and you’ll see a hundred different styles. Which way works best?
Well here’s the most important rule for setting up your task board:
Tip 1 – Don’t add it until you need it
Start simple, with just the essentials. Don’t add something that you think you might need. Wait until you discover that you really do need it, then add it. You might think you need a holding area, or a burndown chart, or a “days remaining” counter, or a standard template for your story cards, or a “QA In Progress” column but you probably don’t. You don’t need to write names of the “assigned” person or the story reference number on task notes. If something isn’t absolutely essential, then leave it out. When you encounter a deficiency and see a way of addressing it by changing your task board, then try it. but only then.
Tip 2 – You only need three columns on your board
- To Do.
Either someone is working on part of the story, or no-one is. If no-one is, it’s either finished or it wasn’t started yet. That’s all.
Tip 3 – You only need three things on your board
- Story Cards
- Task notes
Tip 4 – Story cards are just reminders
The story card must have just two things
- A meaningful title
- The relative size in story points
The story card may often have a reference to a backlog ID, but it’s not essential. The card is just a reminder. If it has a clear, succinct title that means something to the team, then the team will know what that card is all about. It’s current work in progress, it’s fresh in everyone’s mind. It’s a short-lived, throwaway index card. You don’t need to write acceptance criteria (write those in your tests), you don’t need names of developers and product owners (that’s just trivial admin and it doesn’t help anyone). A descriptive title, and a size. The title doesn’t have to be in any particular form, like “As a… I want… So that”. You’ve already gone through the story in detail in your backlog grooming and your sprint planning. On the task board, it’s just a label.
Tip 5 – Use task notes to indicate work done versus work remaining
The task notes are the teams list of little things they have to do to complete the story. Getting the team to produce their detailed task lists in advance is an effective way of revealing any uncertainties or difficulties at an earlier stage. Whereas story cards are index cards, task notes should be post-it notes, because they are numerous, very temporary and subject to change every day. They don’t need to be neat, they don’t need to be kept. incidentally, learn the correct way to remove a post-it from the pad, and they will stay stuck for as long as you want. Do it wrong, curling up the sticky part, and they fall off. To do it right, place the stack on your desk and pull the note almost horizontally towards you while holding down the lower stack, until the note parts from the stack without curling up.
The great thing about using post-it notes for your tasks is that because each note represents a small chunk of work that can be completed in an hour or two, the relative weight of notes remaining “to do” against a story versus “done” indicates progress at a glance, without needing to create a burndown chart.
Get a pack of pink post-its for defects and blocked tasks. It’s a great way for a scrum master to quickly grasp the relative health of the current development, and to home in on problems that the scrum master should be addressing.
Tip 6 – Keep tasks in horizontal swim lanes
The story card goes at the left hand side of the board. Task notes stay in line with that story as they progress. Then you can clearly see which tasks go with which story. When all the tasks are done, the story card moves to done, and the task notes are discarded.
Tip 6 – Put higher value stories higher up the board
The most important story should be at the top, the least at the bottom. Then you can quickly tell if the right things are being worked on. Lots of tasks moving across the board lower down? Problem. High up stories “done” and middle stories “doing”? Great. Lots of stories with tasks in progress but no stories finished? Problem.
Tip 7 – Use magnetic avatars to show who is working on what
If you use a movable magnetic marker to indicate each team member, then you can keep stories and tasks lined up, and the markers are easy to move. If someone isn’t working on something it becomes glaringly obvious. If too many people are working on one thing, it becomes glaringly obvious. As a Scrum Master you can immediately see if people are doing the right things at the right time and mitigate problems before they really start
Tip 8 – Physically move task notes and avatars in the stand up
Make the task board physically accessible and encourage team members to physically move things during the stand up. It makes it clearer for other people, easier to follow what the person has been doing. It helps the person working on that card keep track of what is to do. It keeps the progress and status clear for the scrum master.
Tip 9 – You don’t need a burndown
If your high value stories are at the top, the relative weight of tasks remaining is visually represented by post-its, and the position of post-its shows what is being worked, and it is updated in every stand up, then at a glance you can understand progress. The burndown is just admin, it gives a false sense of accuracy, and it too often doesn’t reflect reality because the task notes are too high-level and not updated. It’s much more effective to encourage team members to use more detailed task notes and to update the regularly. Using post-it notes is so easy to do that it doesn’t put people off. Let them own their task notes, let them do what they want, don’t question their estimates, just let them spend a little time and a little thought to plan slightly ahead of where they are and not be taken by surprise. As a scrum master, it’s much more important that you understand how the developer seems to be getting on, than it is to add up some numbers for an unrealistic chart that nobody looks at. So often the “actual” line on a burndown shows such a remarkable degree of match to the required slope that it suggests a certain degree of sub-conscious “cooking the books”. Starting with the answer you want and working backwards doesn’t give any predictive power.
Some say that the task board is only a snapshot and the burndown gives a trend, but if your stories are small enough then you have all the insight you need at a glance. Put more effort into properly decomposing stories to smaller, independent pieces, and forget the burndown.
The burndown, as usually done, is calculated from remaining task hours. This means it can show apparently desirable progress even though no stories have been completed. Ten stories all “nearly finished” with one or two days to go is dangerous, yet the burndown may look healthy. Smaller stories moving quickly to “done” gives a much better view of progress.
Most experienced scrum teams have given up on burndowns and don’t miss them.
Tip 10 – Use consistent language for your story cards
Story estimating is relative. When estimating a story it helps if you can compare it to similar stories. Your capacity planning is based on the premise that with this sort of work, and this team, in this environment ,with the sort of things that tend to get in our way, and the estimates we tend to give, then we can do this any points per sprint. That becomes easier and more reliable when you can identify similar stories.
One thing that helps is if you use consistent language for similar stories. You tend to get recurring types of stories that relate to similar parts of the product and involve similar work. If you name them consistently, it becomes easier to categorise. Eventually, sizing a story in sprint planning becomes a 30 second effort because you’ve internalized the categorisation of similar work items. Whether the words you’re using are screen or form or page or dialog or preference or option or whatever, if you can quickly classify a story and say “it’s a new screen like the xyz screen last sprint and the abc screen from last month”, and you know they were both 5 pointers, then you have another 5 pointer.
Scrum task board layout – see an example of this layout at