Labels & User Stories

Although both labels and milestones are optional additions to your project management tool, they are useful for categorizing your tasks and tracking larger initiatives.

Set up your labels

Labels are predefined tags on a task that can identify trends or be used for filters and searches.

Recommend Labels

You can choose whatever labels you want, but we recommend a few that we've found helpful. We've also specified the colors that we use for our labels, but feel free to use your own. I advise being intentional with them. They should increase value and not cause a lot of busywork. By default, most tasks should not require any labels.

Label	Color	Description
Customer Issue	Yellow	Flags a task that is linked to a customer submitted or customer-facing issue. These should be resolved as quickly as possible, usually within the next iteration.
Maintenance	Orange	This is a task that isn't specifically part of a user story and is not about feature development. Rather, it signals that this is purely an engineering task to improve the overall system.
Bug	Red	You know what a bug is.
Noncode	Purple	A task that requires significant time (more than an hour) and is not directly related to coding. For any documentation, use "Documentation" instead.
Documentation	Blue	A task that is focused on writing a design document or other documents.
Placeholder	Grey	It either needs to be broken up into meaningful tasks or is just a quick note.

GitHub Projects

Create your task/label/milestone repo

For tasks (issues), labels, and user stories (milestones) we will be using a single GitHub repository (repo). Even if you have multiple engineering teams, we still have one repo for all tasks. This is a bit unintuitive since each repo in GitHub has its own issues, labels, and milestone (which we'll be ignoring). We do this because tasks tend to span multiple repos anyway (maybe one repo is your backend and one is your frontend, and the task requires touching both). Having a unified repo for all tasks helps keep things organized, easy to find, and easy to pass between teams.

There is also no drawback to this: GitHub can easily link pull requests and other issues to any other repo. I highly recommend you don't go rogue on this process.

You can see our example single repo to help guide you.

• Go to your organization.

• Click on the Repositories tab and click New repository.

• Name the repository "tasks". Add the Description: "Reserved for iteration issues, labels, and milestones". Make sure the repository is Private or Internal so only your team can view it. Click Create repository.

• Inside the new repository, select the Issues tab.

• Click Labels.

• There should be a default list of labels, most of which are useless. Edit the labels to meet your needs or follow the recommendations I listed above.

• If you edited your labels to match ours, they should look like what's below.

Trello

• Click on the edit icon by hovering over any card on the board (such as the "Todo" card) and select Edit labels.

• You should have a rainbow of colored labels. Let's name them and change their colors to whatever labels you desire or follow the recommendations I listed above.

• If you edited your labels to match ours, they should look like what's below.

Set up your user stories

User stories (or stories or milestones) are a collection of tasks that make up a larger initiative, such as a feature. Stories are central to agile development. A user story is the summed parts that fulfill value to the user or customer. Typically, you would release all tasks within a user story together. User stories should exist outside of your project management tool as part of your investment, design, and user acceptance testing. They are merely referenced by your tasks.

Actually, Ryan, that's not at all what a user story is.

True, if you're talking Scrum. I'm not. To me, calling a task a user story doesn't make sense. A user story is a great way to give a "why" to a set of tasks while keeping the focus on the end-user.

I prefer the term "user story" over "story", "milestone", or heaven-help-us "epic" because, as with all things in product development, our actions should be centered around the value we offer our users. If something can be a "milestone" but not necessarily a "user story" because it doesn't relate to the user, you should think long and hard about why it'd be worth your attention. And if a user story is just a set of tasks that are bundled together to form a sprint, you are equally missing the point and focused more on productivity than effectiveness.

GitHub Projects

In GitHub, a user story is called a milestone. Just like with labels, you'll want a single repository for all of your milestones.

• If you haven't already, you should follow the steps in the Set up your labels section above to create the "tasks" repository.

• Inside the "tasks" repository, select the Issues tab.

• Click Milestones, then click New milestone.

• You can now give your milestone a Title and a Description. For the description, I recommend linking your investment documents, design documents, mocks, user acceptance testing, or whatever else you have to give context to the milestone.

Trello

There isn't a great way to do this in Trello. Even with Trello Premium, it isn't ideal. I tried several methods, and the best one I came up with I posted below, but I don't know if the amount of clicks and setup is worth the linking of a task to a user story.

• As explained previously, add a Power-Up to your board by searching for "card dependencies" and adding Card Dependencies by Screenful.

Unlike the Agile Tools Power-Up, this Power-Up (along with almost all other Power-Ups) requires you to authorize your Trello account, granting permissions to Screenful. Screenful will have access to your email address, profile, and direct edit access to all your boards on Trello. It's needed for the Power-Up to function, and they have a pretty straightforward privacy policy. But...Ye be warned. 🏴‍☠️

• Add another list to your board, and move it to the left of Status Dictionary. Name it "User Stories".

• Add a card to this list (e.g. "Example Story"), just as an example story. Add another card in one of your iterations, as an example task (e.g. "Example Task").

• Open the example task card ("Example Task"), under Power-Ups click on Dependencies. Set the dependency to Is child to and search for the example user story card ("Example Story") to add the dependency.