Skip to content

Working Process

Jump to bottom
Anton Kovalenko edited this page May 31, 2025 · 3 revisions

UX Design

When it is required to do design tasks, an issue is created in YDB UI repo. Issues are labeled with area/design label.

Design issues are assigned to an iteration in YDB UI project and are discussed during regular daily meetings.

When prototypes are agreed to be good and the design effort is considered to be over, design issue is moved to Done column in YDB UI project and is linked with issues for development, assigned to YDB UI project.

When development is done, assignee of design issue reviews the result on UI test environment.

In order to track design issues ready for review they are added to YDB UI UX project. This project has columns:

  • ToDo – design issues, that are waiting to be done;
  • In Progress – design issues in work;
  • Ready for dev – issues that are finished from design point of view;
  • Design Review – developers who were implementing feature and have done their tasks move linked design issue to Design Review column on [YDB UI UX] project board;
  • Done – issues that were reviewed and all found improvements were implemented

In case some development tickets are created as a result of design review, linked design issue is moved to In Progress.

YDB UI UX project is reviewed during our weekly design review meeting.

Development

Roadmap planning

Once a quarter we have a whole roadmap review session with ydb team. Frequently as a result of this meeting we alter public roadmap.

Weekly

  1. Team uses sprints for planning. Every sprint results in a release.
  2. Every week we have one 1-hour meeting internally to discuss current issues and design future tasks.
  3. Every week we have one half-hour meeting as a demo for users.

Daily

Every day team has a half-hour sync similar to daily scrum or stand-up meeting.

Issue estimation

Team uses story points for estimation.

  • 1 sp – The minimal change that requires neither development nor test revisions. For example, updating text, refreshing an image, or removing unnecessary code.
  • 2 sp – The smallest development task. This estimate is assigned to clear tasks that involve modifying one component and its tests.
  • 3 sp – A complex development task that may involve modifications in multiple components or in the logic of backend interactions. Typically, it's possible to complete two such tasks in half sprint.
  • 5 sp – An unclear task that obviously hides some complexities; it is not clear at the beginning how to proceed. Usually, it's not possible to complete such a task within half sprint.
Clone this wiki locally