I would rather work with physical tools than online, but frankly my own team is highly distributed and so we sometimes need to be able to visualize and communicate our work. Rather than complain about how awful all the online tools are (and how badly wrong default configurations are) let me describe what I really want:
Backlogs are about 80% nonsense. I don't plan all the work I'm going to do. We have found that we are better off if we just do the most important slice of a thing today and get it live, rather than plan how long "the whole thing" would take. We are frugal with our time and investment, and frankly our features need to be validated in production or we don't know that they are really good ideas at all.
Don't treat our backlogs as promises and commitments. They're just a waiting list of things that we might want to do sometime. It should be easy to add/remove.
By the way, you should probably warn us if we have a lot of things in our backlog. Maybe add a WIP limit and warnings to the product backlog. There are real issues and very few advantages to having several years' worth of stories entered into the "backlog black hole."
The most important thing about a story is that it has a title people recognize, and there are a cast of characters who may be working on it.
A cast of characters is not exactly one person. Teams should be encouraged and allowed to work together on stories. And it should be simple to drag one's face from one card to another as the needs of the work change. If a tool doesn't support pair programming and mob programming, then it is hard to understand how it is "agile."
The easiest things in the world should be to split, combine, and delete stories. It shouldn't be a nightmare of clicking, copying, unclicking, reclicking, retyping and the like. This is agile. Stories are fluid. Don't pretend that they're immutable.
Deleting stories is especially important because that's where most of our cost savings come from.
Splitting them is where value delivery comes from so that that should be trivial and not a horrible series of clicks and context switches. Split one into two duplicates and let me change the text as I like.
We don't need to have the explicit ability to enter estimates or actuals into stories. We might want to track lead time and/or cycle time, though. It might be nice to see how long things sit in a non-Done column before being completed but that's mostly for the team's retrospectives.
Finally, we should be allowed to add text and adornments as we choose. We shouldn't be locked into a specific pre-defined set of fields. Think more about "document" than "row in a table." Each story may have unique information and unique marks on it, and the inability to scribble and add stickies and colored marker text/drawings is the primary drawback to using an electronic tool instead of a physical system. How flexible can you make the content and display?
One person shouldn't assign another to anything, and we should never have names or faces attached to work we are not doing yet. Agile isn't about loading up on crushing "promise debt" and individual measurements. In fact, you might want to drop all of your "individual contributor" metrics -- they measure the wrong thing and encourage plate-emptying behaviors.
In particular, realize that we form, reform, un-form, and reconstitute people-per-job all the time. So, let us have images of our faces as tokens. Let us drag our faces from one card to another in the card wall. When a job is complete, return our faces to "available."
Never limit the number of people on a job. Do limit the number of places a single face can occur. Most people can't really work on multiple things at once.
Moving from job to job should be an absolutely trivial gesture instead of a tedious job of opening jobs and "assigning" and "un-assigning" ourselves. It should be a flick of a mouse cursor.
Terminologically, we don't "assign". We "join"
Per-story swim lanes are iffy. People do tasking in such a way that they could have 80% of a story done, but nothing to show for it. We prefer teaching/learning slicing (in CD sense) so that the code always runs and can always be deployed. Having per-story swim lanes is an iffy practice.
Class-of-service swim lanes seem to me to be a good idea. At least I've not convinced myself that it is not. It might be useful to have "Expedite", "Normal", and "Simmer" swim lanes. Consider that.
I know that it sounds crazy, but how about less of these? I'm not a huge fan of burn-down and burn-up (because they assume that the plan is too important). I would love to see cumulative flow diagrams, and cycle time charts of some sort, and maybe some work on traceability between requirements and code.
No individual ranking reports of any kind, ever. No "work by person." No "top contributor." This competition between developers on a team has to die. You only have a great team when all the threats are external. Defending against each other degrades team performance. Threat and assessment kills pairing, mobbing, swarming. Don't let the system become the threat that they defend against.
No team-comparison charts.
I would love to see this tool have good integration to my
- source code control system (git)
- build system (Jenkins)
- test frameworks
- code editors (vim, IntelliJ, eclipse, vs, PyCharm, etc)
- messaging/chat system (slack, mostly)
In other words, I would like it to integrate into my life, instead of being "a web page somewhere that I have to navigate to and do data entry".
Would I use such a system? Probably so.
Would I prefer it to a physical card wall? Maybe.
Would I recommend it over the more comprehensive tools available today? You bet I would.