Product Planning

Hero image for Product Planning

Tools

For managing product planning and development, we are using the following Agile-based project management tools:

While there are differences between these two platforms, we have conventions on how we use efficiently some of the common tools namely attachments, comments and labels.

Attachments

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.

Comments

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

Labels

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.

Features

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

Title

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.

Front-End

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

Back-End

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

Description

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 the design file (e.g. Invision).

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

Estimation

As a generally accepted agile pattern, bug and chore issues are NOT assigned any point as these issues cannot be properly estimated.

Once a feature has all the required meta-data (title, description, acceptance criteria), it needs to be estimated by the development squad.

The estimation can be done either by a single developer or by the whole development squad. We usually do not follow any formal methodology such as Planning Poker but favor open communication. We also accept and actually embrace that estimation can be biased based on who will estimate. As long as the individual or squad who made the estimation is also the one who will execute the work, the estimation will likely be correct and will represent the actual velocity of the individual and the development team over time.

Scale

We use the Fibonacci-based scale 0, 1, 2, 3, 5 and 8 to estimate feature stories.

Estimation Guidelines

When assigning points to a user story, we follow the multi-faceted guideline hereafter:

  • 0 point: no complexity, no unknowns. The effort required is usually less than an hour, e.g. change of text or image.
  • 1 point: no complexity, no unknowns. The effort required is usually between a couple of hours and one day.
  • 2 points: no complexity (as-in “it’s something I have done before”) but it takes more time to implement than a two-point story. So the effort required is usually around 1-2 days.
  • 3 points: medium complexity due to having some unknowns and needs for research. So developers probably know how to do 50% of it only. The effort required is usually between 2-3 days.
  • 5 points: high complexity due to having lots of unknowns because either it requires lots of research or because developers have never done it before. The effort required is usually between 3-5 days.
  • 8 points: indicative that the story is too complex or large, thus needs to be re-worked and broken down into smaller stories.

Statuses

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

Todo

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.

Consequently:

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

Consequently:

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

Consequently:

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

Accepted

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

Rejected

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.