MiniModal Task Screen

"Quick Add" would always be the default. But it is never without contextual data. That has to be enforced.
The current Add dialog would become the Edit dialog.

After checking the documentation for a few apps, the consensus is that a Task is never added on its own. Its always inside a larger context, so all required data will already be available to it. The flow is thus:

1. The Task is created and saved using a minimal form. Task Type, Title, and sometimes Status (Swimlane) is specified by the User;
2. A Row/Card appears on the list, showing the new Task;
3. Then that Task/Card can be clicked to appear in edit mode. Here you see the entire editing form. All other data can be filled in. Child Tasks can now be created on this form because their ParentId is now available.

Step 3 usually will not be necessary. Typically, most Tasks entered just have Titles. Especially if they're not complex.

In Burndown's case, it would not be triggered anyplace else than the following 2 types of places:

1. Nested inside a full parent Task Form, so Child Tasks can be easily created;
   • "project" would be inherited from the parent entity;
   • "priority", would be inherited from the parent entity;
   • "relationships" would be a pointer back to the parent entity;
   • "swimlane" would default to Backlog , but can also be set to any status on the list, as depicted above;
   • TaskType could either be selected or not. I don't know what the consensus is on nesting Epics and such for Project Management. People seem to treat it as an added feature.
2. At the end of each list of cards on "Backlog", "Board" or "Completed" swimlanes, where User wants to quickly create a Task on a Swimlane that is already happening.
   • the "+ Create" link would trigger the minimodal (see the example image above);
   • "project" would already be known and specified.
   • "swimlane" would be set to whatever swimlane the "+ Create" link was in. A selection list for this should not be visible.
   • TaskType would be selectable.

There is another hypothetical use case such as a Trouble Ticketing system where someone might want Users to enter the full editing form. That would be better served by the WebForm module. Then the Ticket Task can be filled properly and assigned by the Project maintainer.

I add a lot of tickets that are not part of an epic. So there are many that I create that are "on their own".

I see that I wasn't clear. "on their own" meant on the screens outside the Projects or Spaces, not as a child of another Task.
I see that I'm incorrect on that, though. I never used or noticed the "+ Create" tag up top next to the Search Bar. The training docs that I used directed us to navigate directly to the Project/Space and use the "+ Create" links in the swimlanes.

That just not match with the reality I live. I have not seen a project yet that does well with only titles for tasks. Not only do I not create tasks like that, I would be disappointed in any engineer I worked with that created tickets like that.

That's why I said "especially if they're not complex." I entirely get your perspective as an senior engineer. However, I'm thinking about it from the perspective of a business manager, organization admin, or a user that just wants to organize their personal life. "Fix the entry lock", "Fire Kate", "Take dog to the vet" don't require anything but the title unless weird stuff happens.

The workflow you are describing of creating a simple version of a task and then having to go find it in the backlog to add detail to it is not one that saves me any time.

Play around with it in JIRA. Its more of a nested form than a modal that floats above. I labeled it incorrectly in the title. When you press "Enter" the card is still under your cursor. You don't have to go look for it.

I can see having a choice to create it in the backlog, or promoted directly to the active board, but I don't understand why we'd want a quick way to circumvent the motion of the board

Some Users' main reason to use the module is to offload these lists that they're keeping in their head. Some of these items have already started when they came to the module. Some have already been completed, and they'd like to make a note of that.

Some Users are also not near a computer for most of the day, so the motion of the board isn't being circumvented. It just hasn't caught up to Life. And that has to happen fast, because it's 3AM and the new day starts in a few hours.

I'm starting to see the need of User Stories. I keep them in my head, 'cause I usually work alone and don't like the extra writing. Would it be helpful if I opened some Issues as Stories?

Also, regarding the "+ Create" links in the swimlanes -- the above example images are from JIRA's Kanban Template. Do you not have the "+ Create" links in the swimlanes on your boards?

I don't know if "Backlog" in Project management is a new concept, or if the self-help Time Management Gurus just decided to skip it. I've only learned of it recently, and I'm starting to appreciate it more and more.

The "To Do" "In Progress" and "Done" structure of the traditional Kanban Board seems too overwhelming in full use, where you have 300+ items in the "To Do" column.
Just for you.
Not a team.
You know most of that list can't be touched for at least a year, and you're reminded of that fact every time you scan it, even though you're just looking for what to do next today.

In my eyes, having the Backlog on a separate screen allows me to peruse, maintain and pick from those when I want to. Not every time I look at the Kanban Board.

It also helps that its presented in the more information-dense List format, which allows visual scanning and picking to be done more efficiently.

All of this to say that I like it the way you've done it here, with the modification we're discussing. Let lower-level users use just the Kanban Board. Enter and move things there. They can expand to utilizing the Backlog when they realize its value.