#6. SCRUM Framework - artifacts, rituals, and roles
We remember Epics, User Stories, and Tasks. Those are common artifacts that are used regardless of which framework the project team uses.
SCRUM framework comes with a few additional artifacts.
SCRUM framework comes with a few additional artifacts.
SCRUM artifacts
- Product Backlog (also called general backlog, global backlog, or just backlog). This is where the team places all tickets (EPICs, User Stories, Tasks, and others). Often the backlog is represented on the Kanban board of the project as the first column in the list.
- Sprint Backlog is a chunk of tickets outlined to be implemented in the next iteration (typically, in SCRUM, one sprint is equal to two calendar weeks). This backlog is also being represented on the Kanban board as a separate column.
- Product Increment, or simply Increment: this is the feature 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.
- DoD, or Definition of Done, is an artifact often used in various frameworks. It is used to agree with all project participants on what 'completion' means for tickets and stages.
For example, the team can agree to consider a task "done" when it functions as noted in the documentation or when a tester changes its status to 'Done.'
An example of all this is in the form of a Trello board:
We implemented SCRUM with an appropriate workspace, placed necessary tasks in the Product Backlog, selected three for the next iteration, and moved them to the Sprint Backlog. The increment, which we can show the customer for feedback, will be created by performing each of the tasks in the Sprint Backlog. Anything we want to keep within our focus is placed in the Product Backlog.
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.
This is a meeting where the team decides what it will develop in the next iteration.
Daily SCRUM meeting, or Standup meeting
This daily meeting is the first of the day, and each team member answers three questions: what they did yesterday, what they will do today, and any difficulties they face. The team meets face-to-face, addressing the whole group, and discussions are welcomed. The meeting should last no more than 15 minutes, with a project manager or facilitator intervening if necessary. Ideally ☺
This daily meeting is the first of the day, and each team member answers three questions: what they did yesterday, what they will do today, and any difficulties they face. The team meets face-to-face, addressing the whole group, and discussions are welcomed. The meeting should last no more than 15 minutes, with a project manager or facilitator intervening if necessary. 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 Demo results, the customer may decide to change or add something, and if so, the team creates corresponding tasks and moves them into the Product Backlog.
Sprint Retrospective
This meeting is scheduled at the end of each Sprint, usually after the Demo. The purpose of it is 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 improve the team's performance continually (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 for now, let's skip it.
Now we know the Artifacts and Rituals of SCRUM. We have a high-level understanding of the working environment and various operational terms. 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 Stakeholder (also known as Customer, Sponsor, or Client). 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.
Let's say we develop software for a large law firm. There might be a few stakeholders from the customer's side. One of them might be authorized to provide us with legal information that we need to take into account, whereas another one might be authorized to request weekly progress reports, etc.
Let's say we develop software for a large law firm. There might be a few stakeholders from the customer's side. One of them might be authorized to provide us with legal information that we need to take into account, whereas another one might be authorized to request weekly progress reports, etc.
Business Analyst, BA. Responsible for understanding the stakeholders' ideas and turning them into documented requirements. One of their most important responsibilities is to ensure communication between the stakeholders and the product development team.
The ideal candidate should have a good general business background and be familiar with the Stakeholder's business domain. They should understand technical aspects of software development (not necessarily be proficient in). The BA translates customer requirements into SRS/PRD/EPICs and/or User Stories and acts as a bridge between the client and the team. In short, they interpret client instructions, answer developer questions, and move requirements into the Product Backlog.
Product Manager is often part of the customer's team. Often they are in charge of product strategy, budgets, estimates, release plans, and feature ideas. The PM differs from the Business Analyst in that they aid non-technical teams (sales, marketing, legal, etc.) while the BA works directly with technical teams (designers, developers, testers). More details about the product manager's role can be found here (click).
Project Manager, PM is a project team member from the software development company's side. They oversee the budget, product delivery, resources, and work amount. They monitor work status and generate reports, and are responsible for resolving project team problems. The ideal candidate should be a passionate leader who embraces "Servant Leadership" (or "Helpful Leadership"), putting aside ego, emotions, and bravado in order to serve the team best.
For the sake of justice, I have to note that it often happens, so the PM also becomes responsible for BA duties. This is a common case in small companies (the majority, though).
Teamlead.Teamlead is the technical curator of the project; deciding the Tech. Stack, distributing tasks, and overseeing execution. The PM and Team Lead work closely together, reporting and requesting resources from higher management; their cooperation drives the project's progress in the short and long term.
Since Team Lead has a closer working relationship with the team than the PM, it is primarily their responsibility to manage the team atmosphere and interaction between the members.
The development team - these are the guys who do actual programming. They write code under the supervision of the Teamlead.
QA team is responsible for the quality assurance of the product. In large companies, this team consists of:
- Testers;
Responsible for the execution of Test Cases (these are documents describing the steps required to test each Increment); - Quality Control (QC) specialists;
They write Test Cases and guide the actions of testers; - Quality Assurance (QA) specialists;
They decide the methodology and plan of testing.
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 - s/he is responsible for writing technical documentation for both internal and external use.
SCRUM framework has three additional roles specific to it:
Product Owner, PO. The PO prioritizes epics and stories and decides what goes into the Sprint Backlog from the Product Backlog
Scrum Master, SM. The SM is like a team psychologist and plays a key role in reducing any risk of decreased productivity due to communication issues, especially in multinational teams. The SM is responsible for keeping tabs on the implementation of all Scrum rituals and the atmosphere of the team, as well as tracking adherence to the four points of the Agile Manifesto.
Agile Coach / SCRUM Coach. Tasked with devising tactics to ensure the successful merging of Agile values and SCRUM framework into the company. The story goes that they have to take into consideration the psychological characteristics of employees, etc. This function was actually created in the West to absolve regular managers from the burden of integrating the framework."
Here are five key values of Scrum, as outlined in Andrew Stellman's book "Learning Agile." I jotted them down a while ago, knowing that their simplicity and accessibility make them particularly helpful in a world of information overload.
5 Key Values of SCRUM
1. Everyone is responsible for the project's success.
- Each participant can express their opinion on the planning and implementation of the project;
- Avoiding extra rules is vital to ensure good communication between everyone on the team. Each person is responsible for the workload, including tasks they don't do themselves.
2. Team members should have mutual respect.
- No one doubts that others will try to do their job as well as possible;
- Each person's job should be made clear so all know its worth. Even the least cooperative team can work well if senior members don't make the junior team members do all the tedious tasks.
3. Everyone should be focused on project objectives.
- Multitasking needs to be avoided, as it is distracting.
4. Teams appreciate openness.
- Ensure full openness in the team and project. Ensure that everyone feels the same level of transparency.
5. Team members must have the courage to defend the project.
- Explaining the importance of the mission can make any task more meaningful. Leaders must give each job a value that people can understand, as this is what motivates them.
Conclusion
We learned about the artifacts, rituals, and roles of the SCRUM framework. We have also got familiar with the roles and responsibilities of project participants.
The following diagram illustrates the topics covered in this article. It shows the communication flow from Stakeholders to the project team and vice-versa.
In the next article, we will analyze the diagram of the adoption and maintenance of the project. We'll try to use all the data that was used in this and all previous articles.