Tutorial: Create your first simple organization

This tutorial is intended primarily for new users of Skriv, who want to manage their projects quickly and who are wondering where to start.

Do not be scared by its length, everything is very detailed to guide you as accurately as possible, with screenshots to be as explicit as possible.

Let’s start with a not too complicated organization. It can still be used to manage real projects − like bugs or support tickets − based on a simple 3-step workflow.

Table of contents

1. Create the organization
2. Define user roles
3. Define workflow steps
4. We do not care about templates or milestones (for now)
5. Add users
6. Create the first bug report
7. Manage bug reports
8. Work progress

1. Create the organization

You can refer to the article written on the subject. Basically, just enter the name of the organization in the form that appears on your homepage:

Once the organization is created, you arrive on its setup page, which has six tabs (Basics, Roles, Users, Steps, Templates, Milestones). Let’s stay on the first tab for now:

In the first part, we can:

• change the name of the organization,
• add a description text (which is displayed when looking at the list of organizations),
• change the color of the banner at the top of the page (which makes it possible to visually differentiate the organizations from each other),
• define which are the working days for the people who work in this organization.

Make the changes you want, then move on to the next part (always staying in the same tab):

This form is used to customize the terminology used by Skriv in this organization, to make things easier to understand.

By clicking in the drop-down menu, choose the type “Buglist”:

This way, Skriv will adapt itself to your usage, displaying “Bugs” instead of “Projects”, and a “Buglist” instead of the “Projects list”.
But if you wish, you can edit each term individually.

The next part of the page allows you to configure Slack notifications. We are not going to take care of it at the moment (but if you want to do it, you can read the documentation on the subject).

Do not forget to click on the “Update” button at the bottom of the page, to save your changes.

2. Define user roles

In the second tab, we will define the different roles that users can play on projects.

There are 4 rights that can be associated with each role; each user who is assigned roles receives the corresponding rights.

• Projects creation: Allows you to create new projects.
• Projects management: Allows you to change due dates, project milestones and assignments.
• Projects prioritization: Allows you to change the priority of projects.
• Notify on project creation: Allows you to be notified when a project is created.

For our example, we will create three different roles:

• Reporter: For people who have the right to make bug reports (right: Projects creation).
• Project Manager: For those who can modify the projects, in order to define their priority and to manage their assignments (rights: Projects management, Projects prioritization, Notify on project creation).
• Developer: For people who solve bugs (no rights).

We obtain the following list:

3. Define the workflow steps

So we go in the “Steps” tab:

In the step creation form, we will enter:

• The name of the step.
• The default duration of the step, in number of days. This information is optional, we will not fill it for the moment.
• Whose stage will be assigned We can choose a specific user (well, we have not created other users yet, so it could only be ourselves), or a role. It is strongly advised to assign to a role, as this offers more flexibility.
• It is also possible to define a step validator. When a validator is designated, the step will only be considered complete once it has been done (by the person who is assigned) and validated (by the validator).

As said in the introduction, we will start on a simple workflow, in three steps:

1. Analysis: The bug has been analyzed to qualify it (whether to treat it or not).
   - Assignment: Project Manager
   - No validator
2. Debugging: The bug has been fixed, it can be put into production.
   - Assignment: Developer
   - No validator
3. Deployment: The fix has been put into production. This is the only step for which we will define a validator, who will be the person who made the bug report; it will have to check that the bug is corrected correctly.
   - Assignment: Project Manager
   - Validator: Reporter

We obtain the following list:

4. We do not care about templates or milestones (for now)

As part of this tutorial, we will not use the tabs templates and milestones, for the sake of simplicity.

Templates are useful when you need to manage a more complex workflow, all stages of which are not enabled on all types of projects. This is not necessary for our simple bug list.

Milestones are used to define time markers on which projects must align their due dates. Depending on your organization, this may correspond to your deadlines, your sprints, your cycles, etc. Here again, we can do without it; if a bug has a time constraint, it can be given a calendar due date.

5. Add users

Everything is in place in our organization to handle bugs. Only users are missing so that the work can begin.

So let’s go to the “Users” tab to see the add user form to the organization:

In Skriv, users are uniquely identified by their email address. To add a user to your organization, just enter her email address; if she does not already have a Skriv account, her account will be created automatically. The user will receive an invitation to join your organization, with the possibility to accept or decline. This invitation is sent by email, and the pending invitations also appear on the homepage:

You can accept or decline the invitation by clicking on the corresponding icons.

For the example, we will create five users with their associated roles:

• Erlich just wants to be able to follow the progress of the bugs, so he has no role.
• Richard wants to be able to make bug reports, be notified when bugs are raised, manage priorities and assignments, and fix bugs: Reporter, Project Manager, Developer
  He will be given Administrator rights, so that he can modify the organization and add additional users.
• Jared needs to be able to make bug reports and manage them: Reporter, Project Manager
  He will be given Administrator rights to him too.
• Gilfoyle does not want to make bug reports, but he must be able to manage and correct them: Project Manager, Developer
• Dinesh must be able to make bug fixes and correct them: Reporter, Developer

We are left with the following list:

Note that it is very easy to change the roles assigned to each user by clicking the buttons. They turn blue when the role is affected, and blank when it is not.

6. Create the first bug report

People who have the Reporter role can create projects. To do this, click on the “+” icon visible at the top right of the page:

If we imagine that the person who creates the bug report does not have the right to “Project Management” (Dinesh, for example), it will have a very simple interface:

The form contains the following fields:

• The title of the bug.
• The associated value, expressed in days (unless you have changed the terminology, to change the words “value” and “days”). This is an optional field, used for informational purposes in the list of projects.
• The description of the bug, which can be formatted (bold, italic, underline, strikethrough, color, lists, tables, links, etc.).
• Attachments.

Once the bug is created, it is visible on its own page:

We can see that this page is very simple. Dinesh does not have a lot of user rights, so he can not do anything but look at the information, without changing it.

7. Manage bug reports

Users with the Project Manager role received an email when this bug report was created. They can also see it in the Bug List:

They can then edit the bug (by clicking on the pencil icon). Compared to what Dinesh had at his disposal, they have 3 additional parts at their disposal: Deadline, Steps and Stakeholders.

7.1 Deadline

Here, we can specify the date by which the bug must be corrected and all of its steps must be completed. This date is optional, which is normal since not all bugs are so critical as to have to be fixed for a specific date.

7.2 Steps

By default, all steps have been disabled:

Activate them by ticking all the boxes:

Let’s not forget to check the “Mandatory step” boxes, because we want the steps to be done sequentially one after the other.

We can set due dates for each step. This can be a good idea in case it is necessary to ensure the progress of the project progress.
Note: When using templates, and defining a project-wide due date, Skriv automatically calculates the intermediate due dates for the steps. This retroplanning feature is very convenient.

We can see that the roles associated with the steps (assignment and validation) are those provided by default when creating the steps. We can modify them for this bug if we wish.

7.3 Stakeholders

In this part, we can choose the people who are assigned to the bug, and what are their roles. You can assign the same person several times with different roles.

Here, Dinesh is by default a mere observer; it is linked to the bug with no particular role. We will give him the role of Rapporteur, since it is he who created this bug report.
We will add Jared as Project Manager, and Gilfoyle as Developer.

Responsive view on tablet and mobile

8. Progress of work

8.1 Analysis

Now that the project has been modified, Jared sees the bug report this way:

We can see that the steps are yellow, which means they are waiting.

Jared can now do his analytical work. Once finished, it can indicate that the first step is completed by clicking on the small “tick” visible in the box of the step “Analysis”.

The page becomes:

8.2 Debugging

Gilfoyle can now debug. Once finished, it clicks in turn on the “tick” which is visible in the corresponding box.

The page becomes:

8.3 Deployment

Jared deploys the hotfix in production and indicates that the step has been completed.

The page now looks like this:

We can see that the last step is always in yellow. Simply because she is now waiting to be validated by the Rapporteur, that is, Dinesh.
Once Dinesh has verified that everything is good in production, he can now indicate that the step is validated by clicking on the icon that represents a shield with a “tick” inside.

The page becomes:

It can be seen that when the last step was completed (done and validated), the entire project was marked as completed. This is visible by the box that is checked at the top next to the identifier and the title of the bug.

It is also visible in the Bug List, in which this rise appears with a “tick” and its title is crossed out:

Conclusion

This tutorial is finished. You now know how to set up an organization and manage projects.

It’s your turn!