#6. SCRUM Framework - artifacts, rituals and roles

So, do you remember what Epic, User Story and Task are? They are common artifacts that are used regardless of which framework is chosen.

In SCRUM, in addition to the general ones, there are a few extra artifacts.

SCRUM Artifacts

  • Product Backlog (also called general backlog, global backlog, or just backlog). This is where we throw all the Epic and User Stories that must be completed to finish the project.
  • Sprint Backlog is where we drag and drop the tasks we need to perform in the next iteration.
  • Product Increment, or simply Increment: this is the product we are going to get at the end of the iteration. Ideally, this is a functional piece of the program that can be shown to the customer for feedback.
  • Definition of Done or DoD is another artifact that is often used in different frameworks. The essence of DoD is to reach an agreement between all project participants about what we consider to be complete before starting the development of the next stage of the project. For example, we can agree that a task (regardless of its type) is considered completed only when it functions exactly as stated in the documentation. Or we can decide that the task is considered completed if the tester has checked it and changed its status to "Done." Although this may all seem obvious, in fact, in each case, the specifics and goals of the project should be taken into account, and DoD should be drafted accordingly. For example, if we have a pilot project, and we don't yet know what a successful completion will look like, then it will be appropriate to have a more flexible DoD, in which the criteria for "accepting" the task will be more abstract, containing only minimal requirements.

Before we move on to the next issue, another element to be aware of is Sprint. A sprint is a period, the duration of which is fixed by the team at the start of the project. Throughout the development of the project, the duration of the Sprint does not usually change, and this allows the team to set a comfortable working pace. Simply put, Sprint is the name for the Iteration in Scrum.

In classic Scrum, the duration of the Sprint is limited to two calendar weeks (ten working days).

Here's an example:


In the above case, there are some tasks in the Product Backlog. We selected only three for the next iteration and moved them to the Sprint Backlog. Performing each of the tasks in the Sprint Backlog will give us an increment, which we will be able to show the customer for feedback. Any new tasks, ideas, users' suggestions – basically anything that we want to remain in our focus will be kept in the Product Backlog.

In conclusion, we have started the implementation of SCRUM. We created an appropriate workspace, threw into Product Backlog all the tasks necessary for a defined and understandable project, prepared Sprint Backlog for selecting tasks for the next iteration (Sprint), and understood what an increment is.

SCRUM Rituals

Rituals are a series of actions that enable you to utilize the full potential of a framework. In Scrum, we use the following rituals:

  • Sprint planning meeting
    This is a meeting where the team decides what it will develop in the next iteration.
  • Daily Scrum meeting, or Standup meeting
    This is a daily meeting, usually the very first meeting of the working day. Each team member answers three simple questions: what did he do yesterday; what will he do today; are there any difficulties that hinder his work. Usually, the team holds these meetings standing up, hence the name. The participants gather face to face, and when answering the questions address the team rather than an individual, so that everyone knows who's doing what. In practice, sometimes these meetings turn into a discussion about the tasks, with colleagues eagerly trying to help each other. In such cases, the person in charge of the meeting (project manager or someone in a facilitator role) should intervene to stop long discussions. The meeting should last no more than 15 minutes. Ideally ☺
  • Sprint Review / Demo
    At this meeting, the team presents the results of their work to the customer, or whoever is responsible for approving the work. Usually, the Demo is held on the last day of the Sprint (usually the last day of the working week). Based on the conclusions reached on the Demo, the team may decide to change or add something, and if so, creates corresponding tasks and throws them into the Product Backlog.
  • Sprint Retrospective
    This meeting is scheduled at the end of each Sprint, usually after the Demo. Purpose: to discuss what went well and what can be improved. The idea is to ensure a healthy, open discussion of the difficulties to achieve maximum team efficiency and, consequently, to continually improve the team's performance (following Agile principle #3).
  • User Story Sizing
     An optional, but recommended ritual. There are many approaches to evaluating the "size" of stories to predict the approximate amount of work that the team can cover in a single iteration. We will analyze the most popular method of evaluation in the next article, so we won't go into any more detail at this point.

Now that we know the Artifacts and Rituals of Scrum, we understand the working environment and related operational concepts, as well as the purpose of team meetings.

Next, let's go over the roles of the project participants so that we gain a complete picture of the participants in our project.

Project Team Roles

  • The interested party (also known as Stakeholder, Sponsor, or Client, although Stakeholder most clearly describes this role). In essence, this is the customer, or a person authorized by him, who has the authority to make decisions or provide specific information for the implementation of the project. For example, if we are writing a program for a large law firm, the stakeholders are the contact persons on the customer's side. For example, one of them might be authorized to provide us with legal information that we need to take into account, and another one might be authorized to demand weekly progress reports from us.
  • Business Analyst, BA. Responsible for understanding the stakeholders' ideas and turning them into a real product (on paper). In addition, one of his most important responsibilities is to ensure communication between the stakeholders and the product development team. The ideal candidate for this role should have a good general business background and be familiar with the sector of Stakeholder's business in particular. In addition, the BA should understand (but not necessarily be proficient in) the technical features of software development. This enables him to interpret the customer's requirements and explain them to the product development team. After gathering instructions from the client, the BA translates the requirements into Epic or User Stories, which, as we know, are slotted into the Product Backlog. As questions arise from the developers, the BA either answers them himself or interprets the questions so that the Stakeholder, who is not a technical specialist, can understand the team's inquiry. In short, the Business Analyst acts as a bridge between the client and the team, since he is competent in both business and technology (a rough but fair synopsis of his role).
  • The Product Manager is usually a member of the customer service team, responsible for product launch strategy, product releases, and development of new ideas and product features. He/she is also responsible for fixing launch dates, organizing training for the team (in cases where the program was developed for internal use in the customer's company), as well as for calculating costs (and profits, if relevant to the product). The roles of Product Manager and Business Analyst are often confused. The key difference between them is that the main function of the Product Manager is to support non-technical teams (for example, sales, marketing, legal, accounting, etc.). The BA, in comparison, works directly with technical teams (designers, developers, testers).
  • Project Manager, PM. Is an employee of the IT company. Oversees the budget, product delivery, resources, and volume of work. Also, he monitors the status of work and generates relevant reports. Another ongoing responsibility of the PM is to resolve team problems. By "team problems," we mean a whole range of things. The ideal candidate for this role should be a fanatic whose obsession is to make sure the team works really well. In the west, an oxymoron concept has been invented to describe this style of work: "Servant Leadership." I guess the essence of the concept would be more accurately conveyed by the phrase "Helpful Leadership." Basically, the idea is that the PM uses his best efforts to serve the team, putting aside ego, emotions, and bravado.

While on the subject of the PM, for the sake of justice, we should also point out that in many companies, this post also includes the functions of Business Analytics. That is, in addition to his PM duties, the PM also ensures communication between his team and the customer. This is often the case in small companies – and bear in mind that there are a lot of small companies involved in software development.

  • The head of the team: Team Lead or simply "Lead." He/she is the technical curator of the project. Usually, it is he who decides the technological stack that will be used in the project (Tech. Stack). He also distributes tasks among the project specialists (developers, testers, and sometimes designers). The Team Lead oversees the execution of tasks, intervenes in the work of junior participants when necessary, and requests additional resources from the PM — but working closely with him. In fact, the PM and Team Lead are the ones who exercise oversight of the course of the project, both in the short and long term. The fruit of their cooperation is reports and requests to higher management.

Since Team Lead has a closer working relationship with the team than the PM, it is primarily his responsibility to manage the team atmosphere and interaction between the members. Where technical support is needed, all meetings with the customer are held with the participation of the Team Lead.

  • The development team: these are the programmers, they are the guys drinking tons of coffee. In fact, they're the actual developers of the project. There are usually three professional ranks (in ascending order): Junior, Mid, and Senior. Categorization is decided by the individual company.
  • Testers team. Ideally, divided into three levels:
    • Tester - responsible for the execution of Test Cases (these are documents describing the steps required to test each Increment);
    • Quality Control (QC) - the role of writing Test Cases and logging the activities of testers;
    • Quality Assurance (QA) - those who decide the methodology and architecture of conducting software testing, as well as how to integrate innovations in testing approaches.
    • In reality, this division into separate roles and titles is common only in really large companies. Small companies simply call label the testing team as "QA," with Junior, Mid or Senior prefixes for each of the members, depending on the candidate's skills and experience.
  • Technical Writer - the person responsible for the development of technical documentation for both internal and external use. This position only occurs in large projects, where the documentation is a crucial aspect of the contract.

In addition to these roles, Scrum has three roles peculiar only to it.


  • Product Owner, PO: responsibilities include the prioritization of epics and stories. In Scrum teams, it is the PO who decides which items from the Product Backlog will go into the Sprint Backlog.
  • Scrum Master, SM: duties include monitoring the implementation of all Scrum rituals, monitoring the atmosphere prevailing in the team, tracking the implementation of key Agile principles (as per the four points of the Agile Manifesto). So the SM is a sort of team psychologist (which is funnier than you might think). But seriously, SMs have a valuable role to play in minimizing any risks associated with a decrease in team productivity arising from internal communication problems. The importance of SMs is increasing in multinational teams, because of the intercultural nature of communication between participants of different backgrounds.
  • Agile Coach / SCRUM Coach. Responsible for developing methods to ensure smooth integration of Agile philosophy and SCRUM framework in a company, team, or project, taking into account psychological nuances of the component, the personal characteristics of the participants, etc. A kind of psychologist-virtue ☺:))). In fact, the role was created in the west to relieve ordinary managers of the responsibility for integrating the framework.

Below I have set out 5 key values of Scrum – from Andrew Stellman's book "Learning Agile." I made a note of them a while back, recognizing that, against the background of the web's information overload, these notes are very simple and easy to understand – and as a result, extremely useful.

5 Key Values of Scrum (from Andrew Stellman's "Learning Agile")

1. Everyone is responsible for the objectives of the project.

  • Each participant can express their opinion on the planning and implementation of the project.
  • It is absolutely necessary to avoid unnecessary bureaucracy to facilitate quality interaction between all team members.
    (Each team member shares responsibility for backlog ... including all functions, not just those that s/he personally works on).

2. Team members should respect each other.

  • No one doubts that others will try to do their job as well as possible.
  • The role of each member of the team should be explained so that everyone understands its importance and significance.
    (Even the most inflexible team can be highly productive, provided some rules prohibit the senior members from transferring the "boring" tasks to the youngest team members).

3. All should be focused on work.

  • In this way, the attention of the team is not divided.
  • Multitasking needs to be avoided, as it is distracting.

4. Teams appreciate openness.

  • Provide enough mechanisms for complete transparency in the team and project.

5. Team members must have the courage to defend the project.

  • Rallying the team around the idea.
  • The role of ideology – explaining the importance of the mission.
    (Digging ditches, isn't exactly elevating or inspiring. But if your role is to dig ditches to protect your city from the enemy, it's still the same work, but much more inspiring. Therefore, the task of the leader (manager) is to endow each job with a value that people can understand, because people are motivated by value)


Let's see what we have learned.

We learned about the artifacts, rituals, and roles of Scrum, as well as the roles and responsibilities of project participants. Now that we know what a Scrum framework is, if we look back, we'll realize that now we understand more deeply the differences between philosophy, methodology, and framework.

In conclusion, have a look at this scheme, which sums up the topics covered in this article: it shows the participation of all the roles together with their responsibilities.


And in the next article, we will analyze the scheme of the adoption and maintenance of the project: this will enable us to finally consolidate all the material which we covered in the last few articles.