Im not a paid developer, I spend two or three hours a day working on a development project as a hobby. As time goes by, I come up with "good-ideas" for the project, that are generally features or bug reports. I would like to manage them using a ticket database. My question is about the "scope" of a ticket. I see from looking at other projects ticketing db that tickets are generally high level features to be implemented, and that these get loosely associated with a feature branch in a VCS.

How do you manage the "To do list" associated with a ticket ? Is it better to "re-write" the original ticket into smaller tasks ? How small of a task rates a ticket ?

4 Answers
4

This is going to vary from person to person and business to business, the model I see most often breaks the Request into deliverable units (one or many based on the scope of the request) Those units become the tickets, and the tickets will have a generalized task list created by an analyst. That ticket will be assigned to a developer who will then look at the tasks, sigh a little, and then break them into a detailed coding unit task list.

Said developer will then be asked to assign an arbitrary % complete number to the ticket and update that arbitrary number by an arbitrary guesstimate every X arbitrary days or arbitrary Project Manager will annoy them or worse yet… pull them into a status meeting

So the ticket tracks the feature, but developers track the tasks in some seperate system , i.e. personal todo list ?
–
user7957Feb 16 '12 at 19:47

The general tasks may be tracked on the ticket, the indiviual units of work the the programmer decides are needed to do the coding are probably going to be a personal thing. Small projects you can keep in your head, otherwise you need a paper or electronic to-do list, whatever works for you. Ususally I keep a paper to-do list, if I get really busy I keep an electronic one mixed with my personal to-do list and a daily paper to do list so i don't forget anything.
–
DKnightFeb 16 '12 at 19:58

Thank you. Since i am a solo developer, would you still suggest that the Deliverable units are all that should be maintained in the Ticket DB ? or should I go down to the Generalized Task item level ?
–
user7957Feb 16 '12 at 20:03

again thank you. We just had a bit of a race condition, and you answered my question before i asked it ...
–
user7957Feb 16 '12 at 20:04

In a very large project - one may keep a Big Functional block as one ticket and so many (development as well testing) tasks continue to evolve till the ticket is finally closed.

In your purpose such a thing won't serve any useful purpose. In your setup, you should focus on one-step-at-a-time (a.k.a. incremental work) which can be tested and be useful after every step.

The size of the ticket should be smallest unit of implementable/testable and useful work. This should itself be as small as a task so that you don't have to really manage tasks separately. Also, after each some atomic activity (feature/task) your build is back to stable before you proceed with any other activity.

Speaking from an Agile perspective, you generally want to create tickets describing stories/features that take you between 1-3 average weeks to complete. This of course may vary from methodology to methodology, however you do want to be able to complete your tickets fairly quickly in order to provide you with real, reportable, and traceable data for later analysis.

If the ticket is too complex, or too large, there is nothing wrong with spawning two or more new tickets, and closing the original ticket off. If your issue tracker has the option to create links between ticket items, then you have the options of referring newly spawned tickets back to their originating issue.

In general, I would start with my features/stories, and list all of the tasks that are required to implement each story. I would provide estimates based on each individual tasks, which collectively would determine the estimate for an entire story/feature.

Normally I try do develop things vertically, so GUI + logic + persistence. If that's too much work I try to make the feature smaller. However sometimes I may just do a bit of GUI with some dummy code attached if I want to get some early feedback on it. I guess the milestone would then be "gather feedback on design idea" or something.
–
JoppeFeb 17 '12 at 20:12