Using GitLab in Agile Environment

User Stories

In agile development methodologies, individual development tasks are broken down into independent user stories. User stories contain a short description of a functionality to be implemented, expressed from the customer’s or stakeholder’s perspective. These stories typically define a simple task that can be developed as an increment and follow a formal structure:

• As a [end user role], I want [the desire] so that [the rationale].
• Starting from the user story, the development task is broken down to the level of work items (task).
• Acceptance criteria are those conditions (requirements) that the developed functionality must meet in order for the Product Owner (PO) to accept it and take over the result of development. Acceptance criteria are connected to user stories but can also be formulated separately. These criteria essentially contain the list of requirements for the given task.

Product Owner

In agile development methodologies, the Product Owner (PO) represents the business side. Their role is to maintain contact with the business, to express business requirements in the form of epics, and to refine them to the level of user stories. For each development cycle, the PO prioritizes the tasks (backlog) based on business requirements. The Product Owner’s task is the business-side verification and acceptance of each increment.

User stories thus represent functions that will be valuable to the system or software user. Although, as mentioned above, the Product Owner is responsible for writing user stories, in reality this is a joint creative activity performed together with the team.

Critical aspects (3C):

When writing user stories or breaking down business requirements into user stories, the following points must be taken into account:

• Card – user stories are written on an actual card (this can be a physical card or an entry in an application).
• Conversation – during the creation of the user story, the expected functionality of the software must be discussed (this can be verbal or documented).
• Confirmation – recorded in the acceptance criteria after all necessary details have been clarified.

The acceptance criteria of a user story are those conditions that must be met during the implementation of the user story in order for stakeholders to accept the delivery. Acceptance criteria can be considered as test conditions, which must be satisfied by tests, meaning that test cases are derived from the acceptance criteria (Acceptance Test Driven Development ATDD). Tests can be executed manually and automatically. Acceptance criteria are usually functional, but care must also be taken not to forget about non-functional requirements and the related test cases. When defining test cases, it is important to ensure that all stakeholders interpret them the same way.

What are non-functional requirements?

Non-functional requirements (NFRs) are specifications that do not define what the system does (functions, business logic), but how it works, i.e. the quality attributes, environment, and constraints of the system.

• Performance
• Reliability
• Security
• Usability
• Scalability
• Maintainability
• Portability
• Interoperability

Definition of Done

This is a team-agreed checklist that defines when a user story, feature, or even an entire release can be considered truly complete. A DoD may include both technical and business aspects. For example:

• Code has been written and passed code review.
• Automated tests have been run, and all are green.
• The functionality meets the acceptance criteria.
• Documentation (user and developer) has been updated.
• The build can be successfully deployed to the test environment.
• No critical open bugs remain.

User stories are derived from project-related epics (an epic is a complex project task that contains all business requirements), and they contain the tasks to be solved in a development cycle (for example, during a sprint in SCRUM). When task planning takes place, the team must provide an estimate of the complexity of the task and the effort required for development. The result of the estimation is a metric that reflects the amount of effort needed to solve the task and has the same meaning for all team members. It has no exact definition and means different things for each team. In the simplest case, it is interpreted as the time spent on development, but as the team gains experience, the metric will increasingly have an abstract meaning.

Why is required time not a good metric?

Because team members have different levels of experience, knowledge, and skills. One member may solve the same task faster than another, while in another task the situation may be reversed. In practice, teams almost always start with time-based estimates, but as experience grows, the metric increasingly means an abstract complexity that team members agree on, even if they cannot precisely define what is behind it.

Providing estimates for project work tasks

As almost every agile team does at the beginning, the teams in this course may also use the required time as the measure of effort.

Interesting and useful information about complexity estimation can be found in this blog.

Let’s give an estimate for the following task!

User story: As a library member, I want to renew books online so that I can keep them longer without having to go to the library.

Acceptance criteria: The system must allow the library member to renew a book that is not overdue and has not been reserved by another member. After renewal, the due date must be extended.

Let’s assume we are the developers of the library system but are not sufficiently familiar with all its modules (i.e., part of the task is to learn the structure and operation of the affected modules).

Planning poker

The technique evolved from the Wideband Delphi estimation method. Team members make estimates by placing numbered cards face down on the table instead of saying them out loud. The cards are revealed and the estimates discussed. By hiding the numbers this way, the group can avoid the anchoring cognitive bias, when the first number spoken sets a precedent for later estimates.

A typical deck contains numbered cards in the Fibonacci sequence, including zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use a similar sequence, with a fixed ratio between values. The use of the Fibonacci sequence is justified instead of simply doubling each successive value, because estimating a task as exactly twice the effort of another gives misleading precision. A task that requires about twice the effort of a “5” should be rated either a little less than double (8) or a little more than double (13).

Planning poker can also be played online

It is not necessary to obtain physical cards to use this technique. Many online, free options are available. For practice, PlanningPokerOnline can be used.

A Management Tool: GitLab

GitLab is an open-source, end-to-end software development platform that offers built-in version control, issue tracking, code review, and CI/CD solutions. The system supports management of development tasks, such as handling tasks and milestones, and ensures their connection to the appropriate elements of the source code. The system provides management of software development processes but has only limited capabilities for supporting project management. For this purpose, other tools (e.g., RedMine) are recommended.

What is CI/CD?

The abbreviation CI/CD comes from Continuous Integration and Continuous Deployment. These practices are part of the software development process.

• Continuous Integration (CI): Developers regularly merge their code into a common version. This practice allows the team to continuously check code quality and detect errors during integration. The CI system automates building, testing, and other processes.

• Continuous Deployment (CD): CD means that code changes are automatically deployed to the production environment. This practice enables fast and reliable software releases. The CD process includes testing, configuration management, and version control.

After the first login to the GitLab available on the internal network, instructors can assign accounts to the appropriate projects (one for practical work and one for team project work).

In this course, you will need to use three main functions of GitLab.

Repository

The foundation of GitLab is git, a distributed version control system. In the GitLab project provided to the teams, the source of the chosen project must be uploaded into the git repository. The “how” (fork e.g., from GitHub, clone into a new repo, copy code and upload as new, …) is up to the teams. It must be indicated which version of the project is the basis.

Distributed vs centralized version control

Version control can work according to two main models: centralized and distributed. Let’s see the difference:

1. Centralized Version Control (CVCS): In this model, versions and changes of the software are stored on a central server. Developers download the latest version from the server and push their changes back. Conflict management is needed if two developers work on the same file simultaneously.

2. Distributed Version Control (DVCS): In this model, each developer maintains their own local copy (repository). Changes are first recorded locally (commit), then pushed to the central server. There is no direct conflict between developers, since everyone works in their own local repo.

Note: Of course, conflicts also occur in distributed systems as well, but they must be resolved locally, choosing which code changes to keep.

Wiki

In GitLab, there is a possibility to create Wiki pages and documentation. For example, test plans, test cases, run logs, and reports can be uploaded here.

If you use this, it is important to create a clear structure. It is not a problem if there are “sandbox” pages, but deliverables must be clear and easily accessible.

Wiki

A wiki or wiki page is a web platform where users create and edit content collaboratively. These may contain static texts, images, and hyperlinks. Their purpose is usually knowledge sharing and documentation.

Issue

Issues are used for recording project-related tasks and bugs.

Since GitLab’s issue tracker is general-purpose, you must ensure the proper structure and content for user stories and bug reports (it is advisable to define a template somewhere).

GitLab provides basic lifecycle management (status: open/closed; assignee; milestone; deadline; and labels), and this lifecycle management system and its elements must be used.

Milestones

Milestones are used to express a certain state or goal. A milestone can have a deadline, but a milestone is not just a deadline, but the set of conditions to be fulfilled. In other words, a milestone is completed when all the issues assigned to it have been solved and closed. In GitLab, milestones can be created on the Plan/Milestones page by clicking the NEW MILESTONE button.

Example milestone: M0 - Preparation

This milestone is completed when all conditions are met for the project to start, namely

• the codebase has been added to the team’s GitLab project,
• all team members have been assigned to the project,
• labels have been defined,
• milestones have been defined, and
• the test plan has been created.

The deadline is October 3.

Labels

Labels allow differentiation, grouping, and status marking of issues. In GitLab, labels can be defined in the Manage/Labels menu by clicking the NEW LABEL button.

What can labels be used for?

• The type of the issue: e.g., type:bug or type:task.
• A more detailed status of the issue, so with labels and the Issues::Board menu, it is easier to track how each task is progressing.
  For example:
• status:new: new, unverified, unapproved task
• status:confirmed: verified, approved task
• status:in_progress: task under development/fix
• status:testing: task under testing
• status:done: successfully tested, complete
• Severity, a kind of technical seriousness/difficulty, e.g., sev:cosmetic, sev:minor, sev:normal, sev:major, sev:critical.
• Priority, i.e. business importance, e.g., pri:deferred, pri:low, pri:medium, pri:high, pri:critical.
• Module related to the issue, e.g., mod:backend, mod:frontend, mod:API, mod:database
• Story points containing estimated effort, e.g., storypoint:1, storypoint:2, storypoint:3,storypoint:5, storypoint:8,...
• and many other things can also be defined.

In GitLab, labels can also be used to create (CREATE LIST button in the Plan/Issue boards menu) Kanban/Scrum boards, which are often used in agile development projects for easy overview and management.

In-class exercise

• Create an issue that contains a task (epic) for developing software to support library lending.
• Create the user story belonging to the previous estimation task and link it to the epic created earlier.
• Create a development task and a testing task for the user story.

Homework

The following task must be solved within GitLab and submitted on the Coospace platform in a documented form with screenshots. The submission must also include the link to the GitLab issue (epic).

1. Create an Epic in your GitLab project:
   • Epic title: “Login module development”
   • Description: The system should allow users to register, log in, and log out.
2. Create at least one User Story linked to the epic, in which the user logs into the system to access their personal tasks.
3. Add acceptance criteria to the user story!
4. Create a development task and a testing task in GitLab and link them to the user story.
5. Estimate the development resources.
6. Create a DoD list at User Story level.

---

Utolsó frissítés: 2025-09-26 07:27:25