What is the way to go to create tasks?

Question

I already read: How to map user stories into tickets?

But I still have difficulties understanding how I exactly should use a ticket system, especially in the case of tickets for new features.

Let's assume the project is at a point, where we know what we have to do, but didn't start any coding. The first thing I want to do now is to bring all the requirements into the tickets system as tasks.

What would a Task-Ticket look like?

Is it a user-story like: As a guest I want to be able to register myself with the site or should I split them into tickets/tasks like Create a registration page/form, Send an email to to the user when registered. Is it a good practice to use user stories, or what is the best way to go?

If this information in relevant: We're going to use the github issue tracking system.

Answer 1

Tasking is usually performed below the story level. Most commonly I see tasks written as directions, i.e., "Do xyz...Create something...Research ABC," etc.

Development stories are generally broken down into 4 different groups of tasks:

1. Research
2. Implementation
3. Code Quality
4. QA/Testing

What is important is to maintain the relationship between the task and the parent user story as the story conveys the value to the customer that underlying tasks should enable upon implementation.

If you use Github to track your tasks, your stories ideally will be stored in Github as well or at least be cross-referenced with whatever other story tracking tool that is employed. Otherwise development members run the risk of losing the context of the task.

Finally, consider that issue tracking and task tracking are 2 distinct activities. Issues are often items that may be transformed into stories or defects after product owner or a lead reviews, judges, and validates the issue.

Stories and defects are the items that are tasked out and worked on by the delivery team. Is there a risk of the delivery team getting pulled into non-task issues if they are tracked in the same system?

Answer 2

My team is still shaking down our toolset and processes, but I am planning to try creating a GitHub milestone to correspond to a feature or user story when we are ready to start decomposing it, then file an issue for every associated task and assign it to that milestone.

This way, I (and my customer-partners, and my management) will easily be able to see all the work associated with the new feature, see progress through the sprint, see new associated work appear as we discover that tasks need further decomposition, and so forth.

Milestones can have due dates, so I can use that for the end date of the sprint. If we're working multiple features/stories in a given sprint, I can just have multiple milestones with the same duedate: this will let me see the progress of each feature independently.

So in your example, you could have a milestone with a shortname, like "Guest self-register" and a description containing the actual story, "As a guest I want to be able to register myself with the site." Then you would have separate issues for Create a registration page/form, Send an email to to the user when registered, and so forth.

But as I say, we haven't actually tried this yet; so I'll be interested to see other answers.