how to break up feature requests into work units

Question

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 ?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.