Planning and Metrics

Let’s KISS the sprint task board

Posted by Ilan on July 12, 2011
I'm Ilan Goldstein and I'm a director here at AxisAgile. I'm a Certified Scrum Trainer and the author of Scrum Shortcuts Without Cutting Corners. Find out more about me or get in contact with me by using the social buttons. I also respond to comments below.

For those sitting on the Scrum periphery, probably the most recognizable element of any Scrum project is the visual team task board. Sitting as the focal centerpiece and gathering point for the team, this colorful, sticky-note-adorned board has almost become the symbol of Scrum. With popularity comes variety, and these days there is no shortage of variations when it comes to board configuration and form factor. While there really is no right or wrong way to create your Scrum centerpiece, you won’t be surprised to find that I certainly have strong opinions on the matter!

Digital or Physical?

Personally, I was a little baffled when I first saw a physical Scrum task board, utilizing low-tech, paper-based sticky-notes, marker pens, and sticky-tack! Why, oh why, would we, as bleeding-edge technical hotshots, go back to the dark ages and use antiquated tooling instead of nice, shiny, oversized monitors projecting slick charts? Well, the answer to the question is simple: human psychology. The pioneers of the task board certainly knew what they were doing when they made the simple, physical board the de facto standard.

The bottom line is that there is something satisfying and gratifying when you get up off your seat, walk to the board (it really isn’t that much exercise, people), pick up a sticky-note, and slap it into the Done column. I feel that the visceral “ceremony” of this movement really appeals to our natural sense of achievement because of the visual recognition of work completed (particularly in an industry where most of the hard work is invisible to others). Also, it doesn’t hurt to make the physical working environment more colorful and stimulating, does it?

Materials Needed to Go Old School

To set up a physical task board, you need the following:

  • Large whiteboard / wall / pane of glass
  • Blue painter’s tape (to create the columns)
  • Large ruler (for your rows)
  • Whiteboard marker (also for your rows)
  • Sticky-notes (two colors)

Setting Up Your Columns

Columns can be set up in a variety of ways. My preference is the following:

Not Started | In Progress | Ready to Verify | Done

Rows of Sticky-Notes

The rows represent the sprint backlog items, including the PBIs (and associated tasks), that will be focused on during the sprint. Don’t use your tape for the rows (just the columns) because the rows will obviously vary per sprint (and retaping every couple of weeks will get very annoying). Basically, each row will be dedicated to a single PBI and its associated tasks.

Each sticky-note represents a specific task item. Try to make each constituent task of a PBI a “vertical,” independently testable slice; otherwise, the Ready to Verify column won’t be as meaningful on a task-by-task basis.

Sticky-Note Content

If you are also using a software tool to help manage your Scrum artifacts, there is a fine line between wasting time replicating details (that have already been captured digitally), on the one hand, and not jotting enough detail on the sticky-notes, on the other hand. The trick is to write just enough on the note to make it identifiable. I recommend that your sticky-notes include the task ID number (that is automatically generated by the software tool), the initials of whoever has taken on the task, a few words describing the task, and the current time remaining (see Figure 1).

Figure 1 - Example content for a sticky-note

Figure 1 – Example content for a sticky-note

Any unplanned work should also be captured on the task board, though I recommend using a different-colored sticky-note. This way you can clearly identify potential improvement areas in the sprint planning process.

Generating the Burndown

I’m a fan of the sprint burndown chart (see Scrum Metrics and Reporting – Measure What You Manage), and if you are using Scrum software, you should be able to automatically generate it on a daily basis. However, even with this option, I prefer updating it manually. It takes less effort to extend the line by a one-day segment than to reprint another chart. In addition, I enjoy the ceremony of updating the burndown in front of the team just before officially kicking off the daily scrum, as I find it adds a healthy air of anticipation!

Some Important Decoration

There are several other artifacts that you might consider printing out in a nice big, bright font and sticking on the wall near the task board (see Figure 2).

Figure 2 - The task board in all its glory along with some “important decoration.”

Figure 2 – The task board in all its glory along with some “important decoration.”

Sprint Goal

The sprint goal (see Sprint Planning – Plan the Sprint then Sprint the Plan) is the umbrella objective that the team is aiming to achieve, so it would be remiss not to display this headline prominently.

Retrospective Goals

After the previous sprint retrospective, the team should have determined the priority process improvements to focus on in the upcoming sprint (see Sprint Retrospective Irrespective). It’s easy to forget about these actions when the team is heavily engrossed in the actual functional work, but if these actions aren’t kept front of mind, then the team will get caught in a vicious cycle where continual improvement is relegated to an afterthought. I have seen teams use a completely separate task board purely for retrospective tasks, but I recommend printing these goals out and sticking them on the project wall.

Definitions and Principles

In the early stages of a project new to Scrum, the team must absorb a lot of new information. Remember that familiar processes and definitions have been turned on their heads, and breaking habitual thinking doesn’t happen overnight. To combat those old habits, displaying the new definitions of commonly referenced elements such as impediments and bugs/issues can be very helpful. Check out this article about dealing with impediments.

Keeping It Real!

In the very early stages of a development project, before the various user stories morph and amalgamate into a slick, well-packaged final product, the team might occasionally lose sight of the big picture and final goal. Following are a couple of suggestions to help everyone keep their eyes on the prize.

High-Level Mock-Ups

In many cases, before the first sprint has kicked off, the product owner will have worked up some high-level mock-ups of the key user interfaces (even if they are just hand-drawn sketches at this stage). Irrespective of how rough they are, it is a great idea to stick a copy of them near the task board to give everyone a constant reminder of the big picture.

Customer Quotes

Unless your team is developing the first product in a start-up, your organization has existing users who, on the whole, really appreciate what you do (otherwise you would be sitting at home playing Xbox). No doubt these users have occasionally offered feedback on what they like and dislike about your product(s). You may hear things such as, “We love the simplicity behind product ABC,” or perhaps, “Product XYZ is so responsive compared to your competitors.” To ensure ongoing success, it is prudent to keep these user signals front of mind. How many times have you seen great products lose their edge because they digress from the core ingredients that made them popular in the first place? I know from firsthand experience that providing visibility on these types of user quotations prompts much more scrutiny when the product owner or other stakeholders start suggesting the inclusion of that extra bell or whistle.

Party Time!

After a particularly difficult sprint, you might be pretty darn excited about throwing all of those sticky-notes straight into the nearest trash can. If trashing the notes provides you some much needed therapy, then go right ahead. However, another suggestion is to keep them all (in the bottom of some drawer) and decorate the release-party room with them for some nostalgia (or perhaps nausea)!

Although the task board might currently be perceived as an exclusive agile tool, I often discuss its efficacy with leaders operating in fields as varied as the legal profession and school teaching, so sit tight, as I don’t think it will be long before these colorful boards start to take over the world!

If you liked this article, you can:
Subscribe to this RSS feed!

About the author

  • Kai

    Great read. Thanks for sharing your great knowledge on how to run a successful Scrum.

  • Nick Skelton

    I think the whiteboard is a good idea – it’s harder to ignore than a webpage. That said, digital cards do allow for better automated dashboards and reports (I want a SCRUM control center!). I think it basically boils down to the adoption period – to babysitting the team for the first couple of weeks, constantly reminding them to update their cards (digitial or physical) until it becomes routine. It also depends on the team itself – a team of devs are more likely to understand and navigate a digital taskboard and will find it harder to avoid an in person daily reminder to update their cards, whereas a team of sales people will be the other way around ;). Learning a lot from your blog!

    • Glad you’re enjoying the blog Nick and thanks for your thoughts!
      There really is no right or wrong with this one but I do recommend trying out the physical board even if it is for one short project – you might be surprised as I was.
      That being said if you are keen to see a range of interesting digital boards, check out the competition recently run by Atlassian (also based in Sydney) for the Ultimate Wallboards Competition

  • Charles Cain

    Great post there llan. Our team went to a physical Task Board back in April 2011 even though tickets are put into JIRA. We chose to do 3 columns instead of 4: To Do, In Progress, and Done. We rolled testing up into the In Progress column mainly to drive home that testing is integral to development.

    Keep up the great articles!

    • Many thanks for your feedback Charles. I also like the 3 column approach i.e. ensuring that testing is seen as integral to development. The primary reason that I personally like the ‘Ready for test/verify’ column is more to indicate to the PO that they are able to sign-off on the work i.e. QA should certainly have been conducted while ‘In Progress’.

      • Charles Cain

        Good morning Ilan,
        The 3 or 4 column approach is certainly viable and of course either will work. The driving force behind us choosing to do the 3 column approach was that QA was very much entrenched in a strict waterfall approach to work. The practice used to be we would develop, then a freeze would occur while QA did their job. Once QA finished, then developers would go back and fix the major bugs found during the QA phase. Other bugs were placed back into the Product Backlog to consider during another sprint.

        When some of our colleagues in another location transitioned over to an Agile system, they tried the 4 column approach since QA was so used to that approach. However, the developers and PO felt like there was no change from what they were doing before and with 4 columns the QA people on the team didn’t really participate in the majority of daily stand-ups unless there was something in their column. When we made our transition over to Agile at our location, we learned from the other team and did the 3 column approach to try and break that cycle. So far it is working really good.

        • That’s some mighty fine inspection and adaption @Charles!

  • Kev

    Hi Ilan,

    I like the idea of manual updating the burndown chart instead of autogenerate.

    On your statement ‘ceremony of updating the Burndown in front of the team just before we officially kick off the daily standup’,

    How do we do this in a practical manner? Does each of them update the remaining hours on task (sticky note), and then someone to update the chart with latest total hours remaining?

    Looking forward to your insight! Thanks.

    • Hi Kev – we actually use digital tracking through TFS as well as the physical board. As such, before the stand-up I will run a calculation to generate the burndown chart figure and then I manually chart that in front of the team just before the stand-up officially begins.

  • Well, as you mentioned, it’s a great feeling to walk to the board, and move one task to the “done” column. Great, I think nobody disagree (while we can’t say that for sure). However, moving a task to the done column doesn’t necessarily mean moving “paper” task to the done column. Why not using gesture detection or even touch to do that? I mean the good feeling is in standing up, going to the board (whether it’s physical or digital), moving something (whether a paper note, or a digital note) to the done column and feeling happy about doing your duty, and then coming back and sit at your desk.

    • Thanks for your comment Saeed and indeed, if you can get budget for nice big touchscreens then that is a great option!

  • I love the thought and illustrative work you put into explaining this Ilan. I’m a huge advocate of analog task boards and have seen how dramatically they can shift team dynamics and engage product owners / passers by.

    I’d like to offer that you don’t need to go ‘old school’ any more if you don’t want to though. Thanks to Kanboards there is an alternative to making a task board with whatever you have laying around the office. Check us out at Our customers love that their sticky notes never fall off!

  • Whiteboards are the best way to get started. They’re far easier to modify as you learn lessons and adapt your process.

Sign up to receive our eNewsletter



Send this to friend