Today, we share a short guide about how to manage software development using Redmine, based on the way we work in RedmineUP. You will learn about our workflow, trackers we use, and how we handle nonatomic tasks. .


We use separate projects for developing our products, custom development, and internal projects (such as support, marketing, and RedmineUP Cloud).

We follow Agile principles with a mixture of Scrum, Kanban and DevOps practises. We organize our work by weekly sprints.


There is no one commonly visible backlog with all issues. Each member of the team can only see theirs

Only the manager can see the general pool of tasks. He is in charge of assigning the issues to team members.

Each new issue receives status "New." Once a developer starts working on it, it's moved to "In Progress."

If a developer has to test the issue, it's assigned to "Release Board" and is designated to a member of the QA testing team. After the test, it returns to the developer.

In case of any questions during coding or if the situation requires further explanation or investigation, the issue is moved to "Feedback" status. The team member receives support from the manager.

Our development process

Each developer follows a detailed 12-step Pull Request Procedure:

  1. The description of an issue is thoroughly read and understood. If anything is unclear, it's clarified by the manager.
  2. Issues have to be carefully tested. This step is very important, as most problems and bugs in software are the result of neglected or careless tests.
  3. Check if the code uses any modified methods. If it was altered, the developer has to check to determine if the logic or algorithm remains unmodified.
  4. Test every visual change. If it's a change in the interface, the developer makes sure it's working smoothly and correctly on all browsers. They find support in Mozilla's CSS reference guide and CanIUse.
  5. Run all tests to make sure they're passed, which includes refreshing the database before running tests.
  6. Create a new branch in GIT.
  7. Push a new branch to the Bitbucket repository.
  8. Verify that all tests on CI are passed.
  9. Create a Pull Request in Bitbucket. Each PR must be mergeable without conflicts. It has to contain an association with the issue, short description, and link to an issue.
  10. Update issue in the Redmine. Each coder adds PR and CI job links for a clear overview.

The next step is to update the issue in the Redmine (10) with PR and CI job links for a clear overview. When developers finish those steps successfully, they can finally move the issue into Resolved status (11) and give themselves a self five (12). :)

The manager checks all issues that are "Resolved" or require any feedback. If no remarks are noted, he closes the issue and assigns it to a final release.


We use three primary trackers:
  • Bug—for fixing bugs and errors
  • Features—for developing new or improving existing functionality
  • Support—to handle support tickets

Managing nonatomic tasks

We do not divide bigger operations into tasks or issues and distribute it among people. We distribute them to team members who are responsible for tasks from start to finish. It's their job to divide it into smaller parts, and if they require any help or support, to ask for it and collaborate with another team member.


In RedmineUP, we only use our products.

Participate in the discussion. Tell us about your workflow for software development projects in the comments. What different trackers do you use? How do you manage nonatomic tasks? Which plugins do you use?