🩴
Bare TechOps
Time and Team Management
Time and Team Management
  • Time and Team Management
  • Practical Agile Development
    • Iteration
    • Task Board
    • Labels & User Stories
    • Tasks
    • Task Estimation
    • Iteration Planning & Review
    • Velocity Tracking
    • Closing Thoughts
  • OKRs & Initiatives
    • The OKR Pipeline
    • My Recommended OKR Tools
    • Closing Thoughts
  • Effective PTO
  • Deadlines
Powered by GitBook
On this page
  • Set up your labels
  • Recommend Labels
  • Set up your user stories
  1. Practical Agile Development

Labels & User Stories

PreviousTask BoardNextTasks

Last updated 3 years ago

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.

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 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.

  • 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

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.

  • 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.

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.

  • 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.

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 . They are merely referenced by your tasks.

Actually, Ryan, is.

I prefer the term "user story" over "story", "milestone", or heaven-help-us "epic" because, , 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.

In GitHub, a user story is called a . 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 section above to create the "tasks" repository.

As , 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 . But...Ye be warned.

that's not at all what a user story
as with all things in product development
milestone
🏴‍☠️
privacy policy
Set up your labels
our example single repo
investment, design, and user acceptance testing
explained previously