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 ?

closed as too broad by user22815, Ixrec, user40980, durron597, gnat Aug 31 '15 at 16:04

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


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

Request (from Customer)
   |-- Deliverable Unit 1(Ticket Item -from analyst - distinct publishable item) 
   |-- Deliverable Unit 2 
   |-- Deliverable Unit 3
            |---Generalized Task Item 1(from analyst - generic to-do list item needed to complete Deliverable Unit)
            |---Generalized Task Item 2
            |---Generalized Task Item 3
            |---Generalized Task Item 4 
                              |-- Detailed Coding Task 1(developer created - breaking down problem into small testable tasks)
                              |-- Detailed Coding Task 2
                              |-- Detailed Coding Task 3
                              |-- Detailed Coding Task 4
                              |-- Detailed Coding Task 5
  • 1
    So the ticket tracks the feature, but developers track the tasks in some seperate system , i.e. personal todo list ? – user7957 Feb 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. – DKnight Feb 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 ? – user7957 Feb 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 ... – user7957 Feb 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.


A feature can be pretty big. I start with formulating what I would expect to see if that feature is complete; acceptance criteria.

This makes the features more actionable because the outcome is expressed in concrete terms. Usually in this process it turns out the feature is really a composition of multiple sub-features.

From there I can typically pick a sub-feature that is really the core or something everything else depends on. I start there and until that bit is done I forget about the rest.

When I have a bite of work I comprehend the further breakdown I do is really low tech, sketches, bullet points on notepaper and lots of yellow stickies.

Yellow stickies are my main external memory and "work breakdown" while working on a (sub)feature. I make and discard them progressively, I don't create a pile beforehand.

If due to time constraints I have to cut scope of a feature I usually convert my undone yellow stickies into new 'issues' or 'stories' for possible feature implementation.

I don't really like the "Create GUI", "Build DB storage" kind of breakdown. Those things are just too obvious.

  • would you consider "Create GUI" and "Build DB storage" Milestones ? – user7957 Feb 17 '12 at 19:49
  • 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. – Joppe Feb 17 '12 at 20:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.