ScrumWorks with a Physical Taskboard

In a discussion group, someone recently wrote:

From the very beginning, the PO has been very insistent that we use an electronic tool, despite the fact that everyone is co-located. I have resisted from the very beginning, because the Team feels that the physical Task Board and burn-down chart are working great. I believe that the PO is focusing solely on her desire for an electronic tool to enable her to more easily maintain the Product Backlog, to readily identify which user stories have been accomplished and which have yet to be completed, and allow for reporting. We’ve bandied about the idea of using [x product] or [y product], but the Team is reluctant to replace our physical Task Board.

The physical taskboard is clearly the best tool for this team. I use taskboards to teach Scrum, and recommend them for co-located teams.

ScrumWorks Pro has a “print to cards” feature for this situation.

You can keep the Product Backlog in ScrumWorks, then print cards after the Sprint Planning Meeting, so your team can use the taskboard during Sprint execution. During Sprint execution, your team members may realize getting the Product Backlog Items (PBIs) done requires additional tasks they didn’t think of. These can be scribbled on blank cards on the physical taskboard.

At the Sprint Review Meeting, your Product Owner can mark PBIs done in ScrumWorks if they meet the acceptance criteria. We’ll measure your rates of velocity, scope increase, etc. with nice graphs and reports you may need for her business stakeholders.

ScrumWorks was designed for Scrum from the very beginning, by people who get Scrum.

Unlike another tool I recently saw a team struggling with, ScrumWorks does not attempt to measure percent done on a PBI according to task status. In Scrum, a Product Backlog Item is only “done” when it’s proven to meet the acceptance criteria, typically at the Sprint Review Meeting.

Also ScrumWorks does not attempt some of the anti-Scrum nonsense of other tools.

–mj
Software Process Mentor (and Scrum Trainer, and ScrumWorks programmer)

Download the PDF version: ScrumWorks with a Physical Taskboard blog

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
4 comments on “ScrumWorks with a Physical Taskboard
  1. Willi says:

    Nice post Michael.

    Recently at my company´ blog I tried to make an original post. That´s the result: http://www.youtube.com/watch?v=g_Y-eHsADrw

    Have fun!
    Willi

  2. Michael James says:

    Great video! I also went to your blog, but I can’t read Portuguese. I did recognize “there is nothing new under the sun.”

    –mj

  3. I love this phrase. I have spent a lot of time lately talking to new ScrumMasters and team members about “unnecessary innovation”. I’ve observed that not just toolmakers but most people who are new to Scrum (or even people who are not that new and should know better) are prone to trying to “innovate” with Scrum usually to their detriment. I believe I’m going to steal “a.S.n.” as shorthand for the concept. (Notice how it evokes the word “aSinine”)

    Jimi

  4. Michael James says:

    Jimi, I enjoyed your post on that topic here: http://groups.yahoo.com/group/scrumdevelopment/message/28438

    I also liked the way Scrum Coach Peter Hundermark put it here: http://groups.yahoo.com/group/scrumdevelopment/message/28450
    No formulaic approach such as described in this post will yield a
    more accurate result, but the danger is that it may *appear* to.

    Still looking for ways to get this message across to people who expect Tayloristic control and predictability from an inherently complex problem space. Some of these people are out shopping for Agile tools and wonder why ScrumWorks deliberately omits things they expect in traditional tools, or all those Scrum-compromised tools (SCTs) out there.

    Michael James
    Software Process Mentor
    http://www.danube.com

Leave a Reply

Your email address will not be published. Required fields are marked *

*