Scrum

Scrum is a process framework for project and product management, particularly for agile software development. It was originally developed in software engineering but is independent of it. Scrum is now used in many other areas. It is an implementation of lean development for project management.

Source "Wikipedia"

Approach

To implement Scrum projects in smenso Cloud, the following points must be taken into account:

• Backlog project
• Sprint project
  • each sprint is a separate project (e.g. Sprint 02/21) and is filled with tasks from the backlog or open tasks from the previous sprint
• Optionally, a "Roadmap" project can also be created to plan epics across years

Structure of the "Backlog" project

Your project folders: Stories | Backlog Frontend | Backlog Backend

 

Type:  ✅ Task  |  🐞 Bug |  🏆 Feature request | 👑 Epic | 📘 Story | 🔍 Retrospective
Story: Story 1  |  Story 2  |  Story 3  |  etc.
Story points: 1 | 2 | 3 | 5 | 8 | 13 | 20 | 40 | 100
Environment: Backend (Cloud/API/DB) | UI/UX | Mobile UI/UX

It is best to display the backlog project in list view. Below is a screenshot of the list view:

As you can see, the individual tasks in the backlog project are further classified by the Flavor type. This allows you to define which tasks are stories, epics, or regular tasks.

Stories 

User stories are often written as a simple sentence and structured as follows:

"As a [customer type] I [want] so that [reason]."

Let’s look at this in detail:

• "As a [customer type]": For whom are we developing? We don’t settle for a job title, but focus on the customer type of the person: Max. Our team should have a shared understanding of Max. Hopefully, we have interviewed many people like Max and can relate to how this person behaves, thinks, and feels. We can put ourselves in Max’s shoes.
• "I want": This describes the intention – not the functions the user uses. What outcome does the customer actually want to achieve? This statement is not about implementation: if you describe a part of the UI instead of the user goal, you’ve missed the point.
• "So that": How does the customer’s immediate desire to do something fit into their bigger picture? What overall benefit do they want to gain? What big problem is being solved here?

User stories could look like this, for example:

• As role A, I want to invite my friends so that we can use this service together.
• As role B, I want to organize my work so that I have more control over it.
• As a manager, I want to be able to track my colleagues’ progress so that I can report better on our successes and failures.

You don’t have to adopt this structure, but it helps you define when your work is done. When the desired benefit for this customer type is clear, the story is complete. We recommend that teams define and consistently follow their own structure.

In the subtasks, the checklist items that are important for a story are defined.

Using the timeline, epics can be planned visually as a roadmap so that you always keep an overview.

Structure of the "Sprint" project

Your project folders: Sprint Backlog | To Do | In progress | In review | Done | Next Sprint | Retrospective

 

Type:  ✅ Task  |  🐞 Bug |  🏆 Feature request | 👑 Epic | 📘 Story | 🔍 Retrospective
Story: Story 1  |  Story 2  |  Story 3  |  etc.
Story points: 1 | 2 | 3 | 5 | 8 | 13 | 20 | 40 | 100
Environment: Backend (Cloud/API/DB) | UI/UX | Mobile UI/UX

The board view is best suited for the sprint:

The tasks to be completed in the sprint are collected in the first folder, "Sprint Backlog", where they can be assigned to the different assignees.

Each assignee can then create their own view filtered to their own tasks, so they don’t lose track of what they personally have to do.

When a task is being worked on, it is moved along the board via drag & drop until it is done or, if necessary, has to be moved to the next sprint. 

If the workflow described here doesn’t fit, additional folders can simply be created or omitted.

Tasks that move to the next sprint are simply moved to the new sprint project.

Of course, all general features such as @mentions, timeline, charts and widgets for visualization are available.

Retrospective

A retrospective should be held after every sprint.

We recommend doing this in smenso Cloud so you can always access older retrospectives – even across projects.

Sprint retrospective agenda

1. What did we do well?
2. What do we need to talk about?
3. What did we learn?
4. What do we need to do differently in future?
5. What have we not yet understood?

Concrete tasks are recorded as subtasks and assigned to specific people.