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.

  • Requirements aren't tasks. User stories aren't tasks, either. Why are you doing this, and how is this question not a duplicate of pm.stackexchange.com/q/9914/4271?
    – Todd A. Jacobs
    Commented Nov 20, 2014 at 3:23
  • Also, are you sure that pm.stackexchange.com/a/9927/4271 doesn't already answer your question? The answer there seems just as relevant to your question.
    – Todd A. Jacobs
    Commented Nov 20, 2014 at 3:24
  • "User stories aren't tasks" - that's why I'm asking, how to do it properly Commented Nov 20, 2014 at 13:15

2 Answers 2


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?

  • Since this is not going to be a big enterprise thing, but more like a learning project, I guess it will be no problem to have task and issues in the same system. Maybe I didn't express myself very well: I want to know the best practice to phrase the things we have to do and store them in the Github issue tracker. Commented Nov 20, 2014 at 13:14
  • You said 4 groups of tasks, but it looks like maybe 5? Research Implementation Code Quality QA/Testing -- I think the word Quality is redundant... can you verify? Commented Sep 18, 2015 at 19:50
  • Couldn't meta-issues be used for user stories? An example of a meta-issue in GitHub is here: github.com/dart-lang/sdk/issues/23454 Commented Sep 18, 2015 at 19:51
  • 1 Research, 2 Implementation, 3 Code Quality, 4 QA/Testing. By research I mean figuring out how to implement the story. Implementation is doing the work to meet the business requirements. Code quality tasks are non-functional requirements that align with DoD for the team. Things like refactoring or paying tech debt. QA/Testing is the domain of automated and manual testing to ensure the customer requirements are met. Also covers things like performance and load.
    – WBW
    Commented Sep 18, 2015 at 20:33

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.

  • I already heard of the approach to use milestones for features, but this is not the way I want to go. Because I want to use the milestones for versions like alpha, beta, launch , etc. Commented Nov 20, 2014 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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