Product Planning

Hero image for Product Planning


To learn more about the tools that we use you can check out our product stack.


Attachments can be very useful. For front-end feature implementation, bug reports or rejection comments, a screenshot can be worth a thousand words.

There is no rule on how to edit a screenshot, but it is common practice in the team to attach one for pointing at specific elements when integrating UI elements or reporting a bug.

For Mac, Skitch is a simple and powerful tool for taking and editing screenshots.


The comments are most useful during the spec’ing phase - to discuss and refine the issues -, and after feature delivery - to detail rejection reasons in particular.

There is no hard rule on comments use or formatting. One general practice, though, is to tag other users when referencing them (reminder: tagging a user is done by typing the @ sign, immediately followed by the username).


Issues meta information can be enhanced using labels to help:

  • Filter issues
  • Provide additional descriptive information

A label must be formatting using kebab-case.

Issue Types

An issue is a backlog item - something that needs to be worked on - and can be of the following types:

  • Feature: a feature of the product that brings value to the end-user.
  • Bug: an issue, unexpected behavior, or broken feature of the app.
  • Chore: a task that does not bring direct value to the end-user, but that is necessary to the product development.


Writing a good feature is important. The difference between a good and a bad feature can be the difference between good and bad implementation.

A well-written feature will give the developers more independence while ensuring an implementation that follows the project specs and design.

There are three parts to a feature:

  • Title
  • Description
  • Acceptance Criteria


A user story is written from the perspective of the user. The story should describe an action that the user can undertake.

For instance, a user story defining the user email sign-in into an application should go like this:

As a user, I can sign-in using my email and password

The user, however, is not always a “user” per se. In an application that has an administrative area, the user can be an administrator.

To re-use the example above, a user story defining the admin sign-in into the admin panel should go like this:

As an admin, I can sign-in into my admin area using my username and password

Front-End vs. Back-End Features

Generally speaking, and especially during the spec’ing phase (as opposed to the development phase), most of the features will go by pairs.

A pair will define the front-end and the back-end components of a feature (labeled frontend and backend respectively).

The main reasons for separating front-end and back-end are:

  • Breaking down a feature in targeted tasks (not all devs in a team have the same skill-set),
  • Allowing for asynchronous front-end and back-end implementation,
  • Leaving back-end developers and designers independent from each-other.

For example, defining a sign-in feature would be done in two stories.


As a user, I can sign-in using my email and password


BACKEND As a user, I can sign-in using my email and password

The two titles are almost identical. The only difference between them is the addition of the BACKEND prefix for the backend story (the prefix must be bolded and capitalized, markdown **BACKEND**).


The feature description is, mostly, used for three purposes:

  • Giving context: why this story/feature? What’s the general mechanics of it? Example:

When signing-in, the standard users (those with the role user) will be redirected to their user profile. The admin users (those with the role admin), will be redirected to the admin dashboard.

  • Adding details: if the feature involves something that isn’t obvious or intuitive, it must be explicitly titled and detailed (titles must be formatted using one #). Example:

Greeting the User

After redirecting the user (standard users only, with the role user) to his user profile, display a greeting message at the top of the screen that reads: “Howdy, {user}. It is nice seeing you again so soon!”

  • Leaving general notes: for when something else needs to be said but doesn’t fall within one of the standard categories detailed above. Notes are usually left at the end of the description and must begin with Note: (markdown **Note:**).

Front-End Specificities

More often than not, front-end stories will involve design implementation.

While this is not possible during the spec’ing phase, once the design is ready, all relevant stories must contain a link to the appropriate design. Add the title **Design** and simply paste a link to the design file (e.g. Invision, Figma).

Back-End Specificities

Back-end stories, when they relate to CRUD operations, must contain a Fields section and list the relevant fields for the story.

The back-end story for a sign-in feature, for instance, could have the following fields:

  • Username *
  • Password *
  • Password (repeat) *
  • Birthday
  • Terms and conditions *

The * sign identifies fields that are mandatory.

Acceptance Criteria

Acceptance criteria will help:

  • Implement the feature as accurately as possible,
  • Test the feature implemented,
  • Decide if a delivered feature is accepted (by the PM or team lead) or not.

For a sign-in feature, the front-end acceptance criteria could be:

  • Disable sign-in button by default
  • Validate email format (to avoid typos)
  • Enable sign-in button when email and password fields have been filled
  • Show error message above sign-in form if sign-in failed


Issues go through mutiple development states whose names vary between tools. But the key states and workflows are actually similar.


This is the defaut state when adding a new issue to the backlog.

At this point, no work has been done yet

In Progress

The assigned team member started working on the task.


  • A new branch has been checked out from the development branch.
  • All commits related to this story will be pushed to the new branch.

Code Review

The assigned team member finished working on the task.


  • A pull request for this branch has been opened OR, if a work in progress pull request had been opened already, the suffix [WIP] has been removed from the pull request title.
  • No new commits will be pushed to this branch.
  • Code reviewers will review the pull request and either approve or reject it. In the case of code reviews requiring the push of new commits, the issue’s status must imperatively be reverted to In Progress when the assigned team member starts working on it again. Doing so is critical. There should not be more than 1 or 2 In Progress stories(s) at a time for each team member. This helps in providing greater visibility on what the current tasks at hand are.

Ready for Testing

The assigned team member finished working on the task and a code review has been completed and accepted.


  • The branch has been merged into the destination branch, as defined in the pull request (development branch by default).
  • The branch for this issue has been deleted.
  • If continuous delivery is set up, the destination branch will be built and deployed (web) / compiled (mobile) automatically to the staging / beta environment.
  • Team leads / PM must review the changes on the staging / beta environment.


The assigned team lead and/or PM reviewed positively the delivered story. This story is now fully completed.


The assigned team lead / PM reviewed negatively the delivered story. Additional work is required.

In this case, the assigned team member will start working on the story again, repeating the full cycle, from In Progress to Code Review, to Ready for Testing, until it gets Accepted.