The software development process

There’s a lifecycle to developing software. Distinct items of work are the foundation of the process. Generally, there are 4 types of items:

1. User Stories: A story is often a new feature or additional functionality. In general, it should add value for users. A good rule of thumb is that anything that requires more than one step to complete or requires more than one person to complete should be a Story. A User Story uses this format: As a [person], I want [a feature], so that [I can do this…]
2. Tasks: A discrete unit of work that a single person needs to complete. For example: “Add a canceled_on column to the account table.”
3. Defects: A defect is a bug. These are things that are broken in your team’s application (usually user submitted). Urgent defects are generally given top priority.
4. Tests: The process of checking your team’s software to ensure it meets the required specification. This includes unit tests, integration tests, user/acceptance testing.

These items go through phases of work. For most teams, the progression looks like this:

1. Someday: This is the default status for all newly created items. These are items that may not be planned for the near term but are items that you would like to work on in the long term. This is a space for new ideas, bugs, and feature requests.
2. Backlog: The backlog contains prioritized items that you’re ready for your team to start working on. Some teams allow developers to go into the Backlog and choose what they’d like to work on next.
3. Current: When someone moves an item out of the Backlog its status changes to Current. The Current column contains all the items that are in progress by your team.
4. Complete: When an assignee completes a given task, whether they close it via a Git commit or click “Finish”, it is marked as Completed. Completed means that the person assigned to the ticket believes they have met the requirements for the ticket. Now it’s time for Quality Assurance (QA) to review it. On small teams QA is often done by the Product Manager.
5. Accepted: Item has been tested, code-reviewed and approved by the Product Manager. In Git, the developer will merge the branch into Master and then deploy to production.

Ship often! With a modern Continuous Integration environment, you should be able to deploy to production 3-5 times a week.

Your goal, as a Product Manager, is to keep the process well oiled. Often, you’ll work with the Senior Dev Manager on this. The key is to have items continuously flowing through the 5 stages.

The next lesson

That’s it for today! The next lesson delves into the topic of identifying product opportunities in the market. You can subscribe to all five (free) lessons here.