XSARUS Redmine workflow
Redmine
Redmine is the central project management tool used by XSARUS. The following three workflows use this tool: projects, development through, and service desk. This document relates to the development workflow.
Redmine prevents information from being delivered to individuals by email or phone and therefore may not be known to the team working on the project. In addition, Redmine provides a fixed workflow for accepting new work and eventually delivering it to the production environment.
Redmine's standard views can appear cluttered with dozens of issues. Using the column, filter and group functionalities will quickly give you a better overview.
Created overviews can be saved so you can easily use them again when you log back in at a later time.
Structuring Redmine
In Redmine, the Business Value column can be added to the statements. You do this by clicking on options in the Issues tab and adding the column BV to the selected columns:
Then in the same screen, clean up the column view so that you only have the columns below selected and group the results by status.
You have now created an overview that contains all the information you need to work in Redmine in a structured way. Save the overview so that it is visible in the right menu under "My custom queries".
Explanation of important columns
In the XSARUS workflow, some columns are leading. Correct use of these columns promotes work flow.
Status
The status indicates the stage an issue is at.
Status options:
- New
- Analysis: doing
- Analysis: done
- Development: to do
- Development: planned
- Development: doing
- Development: done
- Test: to do
- Test: OK
- Test: NOK
Environment
The Environment column combined with the status says something about progress of the issue and the location where the work is taking place.
Environment options:
- Empty
In this case, the issue is not available on any of the environments or is just consulting work that does not require an environment. - Development/Preview/Staging
If an issue is assigned to one of these environments, it is in progress or available on the staging environment for testing. - Production
An issue with the production environment is available on the production or live environment and can be tested on this environment.
Business Value
The Business Value (BV) can be used to indicate the order of issue processing. This works with values from 0 to 100:
- No BV or BV 0: unimportant
- BV 100: urgent
All values between 0 and 100 can be used to prioritize issues relative to each other.
Priority
Priority can be used to bring extra attention to issues (especially during the refinement or plan session), but is secondary to a Business Value.
Assigning issues
In Redmine, you can see in the “Assignee” column who the issue has been assigned to. At that point, the responsibility and action lies with that person.
Is an issue assigned to you and have you followed up on the issue? Then link the issue back to the person who assigned the issue to you.
Do you want to draw someone's attention to an issue? Then use a monkey tail (@) and type in the name:
When you do this, the person will receive an e-mail that he/she has been mentioned in an issue.
My issue overview
If you click on "My page" in the upper left corner, you will see all issues assigned to you in one overview.
Description of issue
Everyone benefits from an efficient throughput and thus a short turnaround time for work. The more completely an issue is created, the sooner it can be refined*. The sooner an issue is refined, the smoother it can be included in the planning.
*Every week, the development team holds a refinement meeting. During this meeting, issues are worked out technically and assessed for complexity based on the information in the issue. This results in an estimate of the number of hours based on the information in the issue. Only when an issue has an hour estimate can it be scheduled during the plan meeting.
Redmine shortcuts
In order to simplify your use of Redmine and reduce administrative tasks, a floating element is available in Redmine containing five shortcuts:
📋 Copy title of ticket
Allows you to easily copy the title of a ticket.
🔗 Copy URL of ticket
Allows you to easily copy the url and title of a ticket, useful for communication with colleagues and communication towards the team you are working with at XSARUS.
📝 Add new ticket description
Allows you to fill the description field of a new ticket with a fixed structure in one click. With this you ensure that the ticket is set up completely and clearly. Under the five headings, work out the issue and save the issue. This ultimately results in the following structure:

🛟 Add problem ticket description
Allows you to fill the field of a new ticket with a fixed structure for describing a problem in one click. You use this structure to ensure that the problem is explained clearly and reproducibly. Under the five headings, work out the problem and save the issue.

👍 Approve ticket (test: OK)
This button allows you to approve a ticket. The status will be updated and the notes of the ticket will ask for possible justification. After this, you can save the ticket.
👎 Reject ticket (test: NOK)
This button allows you to reject a ticket. The status is modified and the ticket notes ask for a justification. After this, you can save the ticket.
XSARUS Workflow
Although much of the work takes place on the XSARUS side, it is a shared responsibility to steer issues smoothly through the workflow. Here the above plays an important role. Finally, the last item to be explained is the issue statuses.
Issue statuses
- Issue status "New" - without environment
An issue has been created and not yet reviewed. - Issue status "Analysis doing" or "Analysis done" - without environment
An issue is accepted and possibly completed by the Consultant or Lead Developer. The issue may not yet be complete due to, for example:
a. The description is incomplete or unclear, more information will be requested or based on the summary information, the issue will be further researched/developed by the author or a consultant from XSARUS.
b. The issue is too big to be dealt with at once. In this case, the issue will be further developed and split into several subissues.
c. The issue has been moved to the backlog because it is not a priority or because it has been temporarily placed on-hold.
Once the issue is complete, the Consultant or Lead Developer will bring the issue into the operational team's weekly refinement meeting. - Issue status "New", "Analysis doing", "Analysis done" - environment development
The issue contains sufficient information to refine it and will be picked up on a Business Value basis during the next weekly refinement session. - Issue status "Development: to do" - environment development
The issue has been refined. This means that an estimate of hours has been made by XSARUS and that the issue can be scheduled if the number of estimated hours is approved. The issue will be scheduled based on Business Value. - Issue status "Development: planned" - environment development
The issue has been scheduled and work will be started within one week. Scheduling always takes place at the end of the work week. - Issue status "Development: doing" - environment development
The issue is in progress. - Issue status "Development: done" - environment development
The work has been completed. The issue is not yet available on staging for testing. - Issue status "Test: to do" - environment development
The issue is available on staging and can be tested. - Issue status "Test: OK" - environment development
The issue has been tested and approved. The issue can be moved to the production environment with the next deploy. - Issue status "Test: NOK" - environment development
The issue has been tested and found not acceptable. A comment below the issue must clearly describe why the issue was not approved. - Issue status "Test: to do" - environment production
The issue is available on production (live environment) and can be tested. - Issue status "Test: OK" - environment production
The issue has been tested and approved on production (live environment).
Need for testing by XSARUS and Customer
In the above workflow/issue flow, issues are tested at least 2x by the customer and/or XSARUS. Testing takes place both on the staging and production environments. Of course, we on our side make every effort to:
- Deliver work within hours estimates and budget
- Meet expectations and agreed upon deadlines
- Deliver quality work
- Despite our 100% commitment and high standards, it can sometimes happen that work is delivered that is not (entirely) satisfactory. Therefore, it is important that both XSARUS and customer employees test issues thoroughly.
Questions?
Other agreements or conditions may apply to your project. Do you have questions about this? If so, please contact your Implementation Consultant.