I run a custom software company. We have three devs, a part time designer and a QA guy, plus me. So, its not a lot of people, but there is workload to distribute.
I use Jira. For simple tasks, I'll just post a description of what needs to be done (move this button from here to there, make this calculation do this instead of that).
For medium difficulty tasks, I'll include a screen-capture video where I discuss the high level purpose of the task "The client is unhappy about how the system does X. They are having to press to many mouse buttons to accomplish their task. I've laid out a different work flow with them. here's what I did and why I did it and what you need to do." Most of the time, this level of detail is sufficient for this type of task. The result I get back is what I was looking for.
For difficult tasks, I'll discuss the task with the team member that is going to be doing the task. Usually, I don't have my head wrapped completely around it prior to talking with them. I'll go over the high level description, talk about the business purpose for what we're trying to accomplish. I'll describe what I think needs to happen, and then solicit input. We'll go back and forth on it, sometimes over the course of days before we nail down a solution. At that point, I'll create a mockup of what needs to be done, but the developer is so well versed in it that he will probably be able to do the whole thing without that. I find that the mockup and technical description is important though because it captures all the stuff we talked about. Its our final chance to review things prior to the task kicking off. Usually, we'll find a few things we didn't overtly discuss that we disagree on. Usually my dev is right, and I'm wrong, but sometimes its the other way around.
Jira is highly configurable, so you can set up workflows however you want them. They have a new version of their system that's a lot more flexible. You can change things on the fly much more easily (adding, removing columns in the workflow, etc).
I have Jira set up with the following columns where I can drag and drop individual tasks into:
1) Backlog (items not yet approved to be done, but stuff we should consider for the future)
2) Approved (Devs can pick from these what they want to do. When we have a lot of things to do, items at the top of the list need to be worked on first)
3) In Progress
4) QA
5) Re-opened (for tasks that failed QA)
6) Done
7) Billed
As far as who gets which assignment, certain guys are good at certain things. Anything transaction related (accounting, inventory, complex calculations or workflow etc) goes to my lead dev. Other stuff can get distributed between the other two. Changes to existing code are given first to the dev that originally wrote it.
I use Jira. For simple tasks, I'll just post a description of what needs to be done (move this button from here to there, make this calculation do this instead of that).
For medium difficulty tasks, I'll include a screen-capture video where I discuss the high level purpose of the task "The client is unhappy about how the system does X. They are having to press to many mouse buttons to accomplish their task. I've laid out a different work flow with them. here's what I did and why I did it and what you need to do." Most of the time, this level of detail is sufficient for this type of task. The result I get back is what I was looking for.
For difficult tasks, I'll discuss the task with the team member that is going to be doing the task. Usually, I don't have my head wrapped completely around it prior to talking with them. I'll go over the high level description, talk about the business purpose for what we're trying to accomplish. I'll describe what I think needs to happen, and then solicit input. We'll go back and forth on it, sometimes over the course of days before we nail down a solution. At that point, I'll create a mockup of what needs to be done, but the developer is so well versed in it that he will probably be able to do the whole thing without that. I find that the mockup and technical description is important though because it captures all the stuff we talked about. Its our final chance to review things prior to the task kicking off. Usually, we'll find a few things we didn't overtly discuss that we disagree on. Usually my dev is right, and I'm wrong, but sometimes its the other way around.
Jira is highly configurable, so you can set up workflows however you want them. They have a new version of their system that's a lot more flexible. You can change things on the fly much more easily (adding, removing columns in the workflow, etc).
I have Jira set up with the following columns where I can drag and drop individual tasks into:
1) Backlog (items not yet approved to be done, but stuff we should consider for the future)
2) Approved (Devs can pick from these what they want to do. When we have a lot of things to do, items at the top of the list need to be worked on first)
3) In Progress
4) QA
5) Re-opened (for tasks that failed QA)
6) Done
7) Billed
As far as who gets which assignment, certain guys are good at certain things. Anything transaction related (accounting, inventory, complex calculations or workflow etc) goes to my lead dev. Other stuff can get distributed between the other two. Changes to existing code are given first to the dev that originally wrote it.