The Perfect Agile Tool - the Task Board

The Perfect Agile Tool – 12 Key Features

The Perfect Agile Tool doesn’t yet exist.  In my training and consulting work, I often have strong words to say about electronic tools.  Most of the tools out there are really bad.  Unfortunately, JIRA, the most common tool, is also the worst that I know of.  (Actually, the only tool worse than JIRA for an Agile team is MS Project – which is just plain evil).  Some Agile tools do a bit better, but most fall far short of a good physical task board (information radiator).  I am often asked to evaluate and / or partner with tool vendors to “bless” their products.  Here is what I am looking for before I will consider an outright endorsement of such a tool.

Features for a Perfect Agile Tool

This list is roughly organized in order of features which do show up in some tools to those which I have never seen or heard of in tools.

1. Skeumorphism: Cards and Wall

The tool should display the current work of an Agile team in a way that is immediately recognizable as a set of note cards or PostIt’s on a physical wall.  This includes colours, sizes, etc.  Most people will type to enter data so fonts should be chosen to mimic hand-printed letters.  Every aspect of the display should remind people of the physical analogue of the tool.

2. Live Update

As team members are using the tool, all updates that they make should be visible as immediate updates to all the other team members including typing, moving cards around, etc.  There is no off-line mode for the tool.  In fact, if the tool is not receiving live updates, it should be clearly disabled so that the team member knows there is a problem with the information they have displayed.

3. Simple or No Access Control

Most Agile methods strongly de-emphaisize or even disallow traditional roles and encourage self-organizing teams.  This means that fine-grained access control to different features of the tool should be eschewed in favour of extremely simple access control: everyone can do anything with the tool.  (It actually helps if there is no “undo” feature, just like there’s no easy way to erase Sharpie written on a note card.)

4. Infinite Zoom In/Out

When you are using cards on a wall, it is easy to see the whole wall or to get up close and see even very fine details on a single note card.  Although it does not have to be literally infinite, the wide and tight zoom levels in the tool should be at least a few orders of magnitude difference.  As well, the zoom feature should be extremely easy to use, similar perhaps to the way that Google Maps functions.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

5. Touch Device Compatible

This seems like a super-obvious feature in this day and age of tablets, smart phones and touch-screen laptops.  And it would take the cards on the wall metaphor just that extra little way.  But very few tools are actually easy to use on touch devices.  Dragging cards around and pinch to zoom are the obvious aspects of this feature.  But nice finger-drawing features would also be a big plus (see below)!

6. Size Limit on Cards

For techies, this one is extremely counter-intuitive: limit the amount of information that can be stored on a “card” by the size of the card.  It shouldn’t be possible to attach documents, screen shots, and tons of meta-data to a single card.  Agile methods encourage time-boxing (e.g. Sprints), work-boxing (e.g. Work-in-Process limits), and space-boxing (e.g. team rooms).  This principle of putting boundaries around an environment should apply to the information stored on a card.  Information-boxing forces us to be succinct and to prefer face-to-face communication over written communication.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

7. Minimal Meta-Data

Information-boxing also applies to meta-data.  Cards should not be associated with users in the system.  Cards should not have lots of numerical information.   Cards should not have associations with other cards such as parent-child or container-contained.  Cards should not store “state” information except in extremely limited ways.  At most, the electronic tool could store a card ID, card creation and removal time-stamps, and an association with either an Agile team or a product or project.

8. Overlapping Cards

Almost every electronic tool for Agile teams puts cards in columns.  Get rid of the columns, and allow cards to overlap.  If there is any “modal” behaviour in the tool, it would be to allow a team member to select and view a small collection of cards by de-overlapping them temporarily.  Overlapping allows the creation of visually interesting and useful relationships between cards.  Cards can be used to demarcate columns or groupings without enforcing strict in/out membership in a process step.

9. Rotatable, Foldable, Rip-able Cards

Increase the fidelity of the metaphor with physical cards on a wall.  Rotation, folding and ripping are all useful idioms for creating distinct visual cues in physical cards.  For example, one team might rotate cards 45 degrees to indicate that work is blocked on that card.  Or another team might fold a dog-ear on a card to indicate it is in-progress.  Or another team might rip cards to show they are complete.  The flexibility of physical cards needs to be replicated in the electronic environment to allow a team to create its own visual idioms.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

10. Easy Sketching on Cards… Including the Back

Cards should allow free-form drawing with colours and some basic diagramming shapes (e.g. circles, squares, lines).  Don’t make it a full diagramming canvas!  Instead, allow team members to easily sketch layouts, UML, or state diagrams, or even memory aides.  The back side of the card is often the best place for more “complex” sketches, but don’t let the zoom feature allow for arbitrarily detailed drawing.  Lines need a minimum thickness to prevent excessive information storage on the cards.

11. Handwriting Recognition

With Siri and other voice-recognition systems, isn’t it time we also built in handwriting recognition?  Allowing a team member to toggle between the handwriting view and the “OCR” view would often help with understanding.  Allow it to be bi-directional so that the tool can “write” in the style of each of the team members so that text entry can be keyboard or finger/stylus.

12. Sync Between Wall and Electronic Tool

This is the most interesting feature: allow a photo of cards on a wall to be intelligently mapped to cards in an electronic tool (including creating new cards) and for the electronic tool to easily print on physical note cards for placement on a wall.  There is all sorts of complexity to this feature including image recognition and a possible hardware requirement for a printer that can handle very small paper sizes (not common!)

Key Anti-Features

These are the features that many electronic tools implement as part of being “enterprise-ready”.  I’ll be brief on these points:

No Individual Tracking – the team matters, not who does what.

No Dependency Management – teams break dependencies, tools don’t manage dependencies.

No Time Tracking – bums in seats typing doesn’t matter: “the primary measure of progress is working software” (or whatever valuable thing the team is building) – from the Agile Manifesto.

No Actuals vs. Estimates – we’re all bad at predicting the future so don’t bother with trying to get better.

No Report Generation – managers and leaders should come and see real results and interact directly with the team (also, statistics lie).

No Integration Points – this is the worst of the anti-features since it is the one that leads to the most anti-agile creeping featuritis.  Remember: “Individuals and interactions [are valued] over processes and tools” – from the Agile Manifesto.

Evaluation of Common Agile Tools

I go from “Good” to “Bad” with two special categories that are discontinuous from the normal scale: “Ideal” and “Evil”.  I think of tools as falling somewhere on this scale, but I acknowledge that these tools are evolving products and this diagram may not reflect current reality.  The scale looks like this, with a few examples put on the scale:

Perfect Agile Tool evaluation scale with examples

Plea for the Perfect Agile Tool

I still hope that some day someone will build the perfect Agile tool.  I’ve seen many of the ideal features listed above in other innovative non-Agile tools.  For example, 3M made a PostIt® Plus tool for the iPhone that does some really cool stuff.  There’s other tools that do handwriting recognition, etc.  Putting it all together in a super-user-friendly package would really get me excited.

Let me know if you think you know of a tool that gets close to the ideal – I would be happy to check it out and provide feedback / commentary!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

21 thoughts on “The Perfect Agile Tool – 12 Key Features”

    1. I checked out their web site. Fancy-looking. I suspect I would categorize it somewhere between Agile Zen and the full Rally product. Interestingly, their lower price-tier versions may actually be better. For example, fewer reports, limited APIs. Have you used it? If so, I would be interested to hear your analysis.

  1. Mishkin, simplicity sometimes masks naivety. Attractive header, poor content, neglecting team setups other than a single co-located team only working during office hours. Why you would even consider MS Project, and do no proper review of supportive tools used at actual teams. Are overlapping cards really readable and ideal? While I can see value in some of your points, simply bashing all alternatives isn’t smart. Am I right seeing a day to day planning in your picture?

    1. I assume your are critiquing my article. I know that it is, at this point, still very shallow. I haven’t really said much about “why?” I think these are good features for an electronic tool. I believe that a co-located single team should never use an electronic tool. So, in fact, the existence of this article is all about me considering distributed and multiple team situations. I mentioned MS Project because I have heard of enough cases of PM’s trying to use it to manage Agile teams and because someone put enough thought into its use to produce a 1-hour tutorial video on using it for Agile. As for other tools, I hope to get to reviewing many of them, but I would like to focus on those that might actually be good… And I don’t know if any.
      The picture illustrates a team using its wall area for complete Agile planning and work status including work done in past iterations, the current iteration, planned future iterations and current quality issues.

    1. That looks super cool!!! Thanks for sharing! Are you using it yourself or involved in development of wallsync? If so, I would love to hear more about it from you… maybe even a guest article?

  2. JIRA (actually is the JIRA Agile add-on) has a lot of limitations. I would like to hear what specific things the author don’t like. Thanks.

    1. Hi Mishkin

      Sorry for the late response. I didn’t see your comment.
      I’ve tried many such tools, Jira, Rally, Version One, Mingle but I keep coming back to Target Process. You get so much functionality and flexibility for your ‘buck’ and they listen and adapt the product. I have used TP on so many different types of project now, not just Dev IT.. marketing, helpdesks, construction it’s so customizable it will fit into so many areas with a low learning curve. The graphical, intuitive nature of the UI makes it so easy to navigate and find items.
      Give it a try and get TP to show you how to get started. It won’t be wasted time believe me.

  3. We just started using JIRA. We use it primarily for backlog management and for that purpose at least we like it better than Excel and Trello (our previous “solutions”). We use a physical board for tracking stories and tasks during the sprint as well as a physical burn down chart.

    I’m surprised with the JIRA hate. Is your beef with the tool itself or how it is used in most organizations?

    1. Hi René. Please don’t misunderstand: I don’t “hate” JIRA. I just think it is the worst possible choice for an electronic Agile tool. If anything, I “hate” MS Project when it is used to manage Agile teams. As you have described, JIRA used for backlog management is not quite as bad: you can still do physical tasks etc. for your team, and this is a very reasonable mix of electronic and physical. But even with it used for backlog management, there are still many things about JIRA (and other electronic tools) that leave a lot to be desired. For the use that you are putting it to, how many of the ideal features that I list does JIRA have? I would guess that it is just one or two, and at the same time it is breaking some important ones. For example: how much information are you storing in each backlog item? If it’s more than a couple sentences, then it is a mis-use of the tool… and that mis-use is enabled and even encouraged by the tool.

      So, indeed my concern is with how electronic tools are used in most organizations… and that mis-use is most often enabled and encouraged by the tool itself.

  4. Hi,

    We are using Agilefant. Stories are easy to drag-n-drop from one iteration into another and you can easily see your work queue. Overall for that price I think it works fine. They seem to have a Trello plug-in also, so it would be interesting to read a review how that works.

  5. Mishkin, Thank you for starting this thread… its a subject that is very topical… how does technology REALLY support the actual process…

    We all know the benefits of Visual Management, and the collaboration achieved when gathering around an Obeya can be difficult to quantify, but are one of the most significant drivers of “making the change”…

    I agree with you that there is no one single technology in my mind that fits the bill… how do you replicate the “Obeya”?? gathering together in a room and looking at a small screen just doesn’t give the same result… so… can we go big? Can we create a digital wall?? Sure… with time and money anything is possible…

    The answer is somewhere in between I think… all these tools you’ve mentioned here have some inherent value.. I haven’t seen a “one-size-fits-all” here… I guess each of us need to figure out what works in our specific environment

  6. Just finished reading this article to find a better solution other than JIRA, but one mentioned in the article “Agile Zen” is no longer taking new customers… Just informational purposes.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.