What are the Full Scrum Artifacts?

Artifact (software development) is one of many kinds of tangible by-products produced during the software development.

In the scrum project management framework for software development, scrum artifacts refer to documentation used for managing work in the project.

Scrum is a framework for developing and maintaining complex products. It originated from software development projects, but it is suitable for any complex or innovative projects.

Scrum uses an iterative and incremental approach to optimize predictability and control risk. Exactly it's one team that works. The whole development process consists of several short iteration cycles in this framework. A short iteration cycle is called a sprint, and the recommended length of every sprint is 2 to 4 weeks (The one-week sprint can be used for Internet product development).

1. Scrum Structure：3-3-3-5-5

Most people know the scrum structure as 3-3-5. Fewer people know the scrum structure as 3-3-3-5-5.

3 Scrum roles: Product Owner, Scrum Master, and the Scrum Team
5 Scrum events: Sprint Planning Meeting, Product Backlog Refinement, Daily Scrum Meeting, Sprint Review, and Sprint Retrospective
3 Scrum artifacts: Product Backlog, Sprint Backlog, and Product Increment
5 Scrum values:Commitment, Focus,Open,Respect,Courage
3 Pillars in Scrum：Transparency, Inspection, Adaptation

1.1 Three (3) Scrum Roles

The roles in Scrum are pretty different from the traditional software methods. Clearly defined roles and expectations help individuals perform their tasks efficiently. In Scrum, there are three roles: Product Owner, Development Team, and Scrum Master. All these together are known as the Scrum Team.

The three different types of roles in Scrum

1.1.1. Product Owner

The product owner defines the why, who, and why it is worthwhile to develop a product, who it is for, and what features it should contain. They own a product entirely; they have the final word on strategic and tactical product decisions. The PO maximizes the product's value for the users, customers, and the business.

1.1.2. Scrum Master

The Scrum Master helps the Scrum teams learn and apply Scrum to achieve business value. The Scrum Master is not the manager of the Team members, nor are they a project manager, team lead, or team representative. Instead, the Scrum Master serves the Team; A Scrum Master is a facilitator and Servant Leader who encourages and demands self-organization from the development team. A Scrum Master enables close cooperation across all roles and functions to address resource issues and scrum practices disobedience.

1.1.3. Scrum Team

A Scrum Team consists of individuals working within that framework to meet a Product Goal or quickly provide adaptive solutions to a product problem, or as defined by Scrum Theory, within an incremental period referred to as a Sprint.

1.2 Five (5) Scrum values

Commitment - Willing to commit to goals.
Focus - Put your mind and ability into the work you promise.
Open - Scrum opens everything in the project to everyone.
Respect - Everyone has his unique background and experience.
Courage - The courage to commit, keep it and accept respect from others.

5 Scrum values

1.3 Five (5) Scrum Events

5 Scrum Events

The Scrum framework outlines 5 events that take place in the scrum process: The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and the Sprint Retrospective.

First and foremost, we should understand Sprint as the core of the Scrum process that contains all other events within a consistent, fixed time box. For example, Sprint Planning happens within a time-boxed Sprint, as does the Review and Retrospective. The Sprint model also enables the three core pillars of Scrum, transparency, inspection, and adaptation, which we will outline further.

Sprint Planning occurs at the beginning of a sprint, typically 2-hours a week per iteration. The planning meeting allows the Scrum Team to define their Product Goal and the work necessary to complete it. The Product Owner will ensure the planning meeting is fit to discuss critical product backlog and related items.

Daily Scrum(or Stand-Ups): a daily, short 15-minute "check-in" for the team to assure tasks are moving smoothly. Questions to ask are: What did I work on yesterday? What am I working on today? What issues are blocking me?

Sprint Review: time allotted to review each team member's work and progress, provide feedback, and test iterations. Reviews are meant to be casual, celebratory, and culture-driven. Each team member is valued and encouraged in their accountability.

Sprint Retrospective: allocated time to align with core values of Scrum and assure both agility and effectiveness. Retrospectives are meant to assure that both communication and scrum process is effective and provide tweaks to embody future success toward the Product Goal or Sprint Goal.

1.4 Three (3) Pillars

The three pillars support implementing each empirical process control: transparency, inspection, and adaptation. The three pillars of Scrum are as follows:

3 pillars of Scrum

Transparency

In Agile project management, transparency refers to maintaining a high degree of visibility in all aspects of the software development process, influencing all aspects of the delivery results, and being transparent to all those who participate in the delivery and those who manage the production results. Team members who manage production outcomes must be able to see these aspects of the process and understand what they see. That is to say; when someone is testing a process and is sure that a task has been finished, the completion must be equivalent to the team's definition of done.

Inspection

All aspects of the development process must be checked frequently enough to ensure that significant deviations in the process can be found in time. When determining the inspection frequency, it is necessary to consider that it will cause changes in all processes. When the specified inspection frequency exceeds the allowable level of process inspection, problems will arise.

Adaptation

Suppose the inspectors find that one or more aspects of the process do not meet the acceptance criteria, and the final product is unqualified. In that case, the process or materials need to be adjusted. The adjustment must be carried out as soon as possible to reduce further deviation.

1.5 Three (3) Scrum Artifacts

Agile project management can help a wide variety of projects, but if it is not fully understood, there will be problems. There are unique terms and ways of working in agile that can be bewildering for those new to the methodology. Product and sprint backlog are two potentially confusing terms in the scrum artifacts. These artifacts are essential for planning and prioritizing tasks in a project.

Product Backlog and Sprint Backlog Process

1.5.1 Scrum Artifacts 1: Product Backlog

The Product Backlog is the Product To-do List

The Difference: Product, Release, and Sprint backlogs | Aha! software

In the scrum artifacts, the product backlog is a sorted list that contains all the things the product needs and is also the only source of product demand changes(user stories). The product owner is responsible for the content, availability, and priority of the product backlog.

The product backlog is a continuous improvement list. The initial version only lists the initial and well-known user stories. It evolves as the product and development environment changes. The backlog is dynamic and often changes to identify what is necessary to make the product reasonable, competitive, and valuable. As long as the product exists, the product backlog exists.

The product backlog lists all the features, functions, requirements, improvement methods, defect repair, and other changes to the future release products. Product backlog entries contain characteristics of description, order, and estimation.

The product backlog is usually sorted by value, risk, priority, and necessity. It is a sequence from high to low priority, and each item has a particular order. The top product backlog items need to be developed immediately because they convey the critical information of the tasks. The higher the ranking, the more urgent the items in the product backlog are, the more careful they need to be considered, and the more consistent they are about their value.

The product backlog items that the R&D team will develop in the next sprint are fine-grained and have been decomposed. Therefore, any item can be "completed" in the sprint time box. The product backlog items that the R&D team can "complete" in a sprint are considered "ready" or "executable" and can be selected in the sprint planning meeting.

The product backlog has become a more extensive and more detailed list using products, value acquisition, and market feedback. Because requirements never stop changing, the product backlog is a constantly updated artifact. The change of business demand, market situation, and technology will cause the change.

Carding is a part-time activity in Sprint between the PO and the development team. Usually, the development team has self-optimizing domain knowledge. However, when and how to complete the optimization is the scrum team's decision. Optimization usually takes no more than 10% of the R&D team's time.

The development team is responsible for all the estimates. POs can influence their decisions by helping the team weigh the trade-offs. However, the final estimate is determined by the person who performs the work.

Monitoring progress toward the target at any time, the remaining workload to achieve the goal can be accumulated. Product leaders track the total remaining work remaining during each sprint review. The PO compares this amount with the remaining workload of the previous sprint review to assess the progress of achieving the expected work at the desired point in time. This information is transparent to all stakeholders.

Trends burndown diagrams, combustion diagrams, and other planning practices can be used to predict progress. They have been proven beneficial. However, this cannot replace the importance of empiricism. In a complex environment, what will happen is unknown, and only what has happened can be used to make forward-looking decisions.

The Role of PO

The product backlog is created by the product owner, who is the project’s key stakeholder and therefore has a full vision of the project. The product backlog is a kind of scrum guide for the agile team and therefore must be written out clearly and simply to avoid any miscommunication or misunderstandings.

To make the process as thorough as possible, it must be organized, and each item explained in full as part of the plan to move successfully through the project.

The product owner knows what the customer wants and can work backward from there to make sure everything is to meet the definition of done. That’s the product owner’s lodestar, and if the customer’s interests are always leading the backlog, the work will be effective.

1.5.2 Scrum Artifacts 2: Sprint Backlog

Sprint Backlog is One To-do List

In the scrum artifacts, Sprint backlog is a set of product backlog entries selected for the current Sprint, plus plans to deliver product increments and achieve a sprint goal. The sprint backlog list is the R&D team's estimate of which features will be included in the next increment and the work required to deliver those features.

Sprint backlog defines a development team's work to convert a product to a "done" increment. The sprint backlog clarifies what the R&D team has determined is needed to achieve sprint goals.

The sprint backlog is a plan that is specific enough to make progress changes understood in daily meetings. The R&D team will modify the backlog in the whole Sprint, and the backlog will gradually appear in the process. For example, the R&D team will work according to the plan and better understand the work required to complete the objectives.

When a new assignment appears, the R&D team needs to add it to the sprint backlog. As the task progresses or is finished, the estimated remaining workload of each task needs to be updated. If a part of the plan loses its meaning, it can be removed. Within Sprint, only the R&D team can modify the sprint backlog. The sprint backlog is highly visible and is a real-time reflection of the team's plans to complete work within the current Sprint. Moreover, the list only belongs to the R&D team.

When the product backlog function point is put into the fixed cycle of Sprint, the sprint backlog will change for the following reasons:

With the change of time, the R&D team understands the user stories and may find that some new tasks need to be added to the sprint backlog.
Program defects are added as new tasks, all unfinished tasks in the commitment to submit tasks.

The product owner may work with the Scrum team to help them better understand what a sprint goal is. ScrumMaster and team may feel that minor adjustments will not affect Sprint's progress but will bring more business value to customers.

Monitor the Progress of the Sprints

The sum of all remaining work in the sprint backlog can be calculated at any point in the Sprint. The R&D team tracks all remaining work in the daily meeting. The R&D team tracks the remaining sum daily and predicts achieving sprint goals. The R&D team can manage its progress by continuously tracking the remaining work.

Scrum doesn't consider the working time already spent on the backlog. Its only care about the remaining work and the date. Follow up progress through burn down chart.

In Scrum, the sprint burndown chart shows the accumulated remaining workload, which is a trend chart reflecting the status of workload completion. The y-axis represents the remaining workload, and the x-axis represents the working days.it describes the picture of the work.

At the beginning of a sprint, the Scrum team will mark and estimate the detailed tasks to be completed. The workload of all tasks that need to be completed but not completed in the Sprint is called Cumulative Workload. The team will update the cumulative workload every day according to Sprint Progress. If the cumulative workload is reduced to 0 at the end of the Sprint, the Sprint will be successfully completed.

Since the increased task workload may be greater than the completed task workload at the beginning of Sprint, the burndown chart may show a slight upward trend.

Release Burndown Chart

In the Scrum project, the team tracks the progress of the whole release plan by updating the release burndown chart at the end of each Sprint. The published burndown chart records the trend of the total remaining estimated workload of the product backlog over some time. The x-axis represents the project cycle, with Sprint as the unit. The y-axis represents the remaining workload, usually with user story points, ideal person-days, or team days.

1.5.3 Scrum Artifacts 3: Product Increment

The product increment is the sum of all the product to-do list items completed by a sprint and the sum of the incremental values generated by all previous sprints. At the end of Sprint, the new increment must be "done", which means it must be available and meet the standard of the scrum team's definition of done. Increments are viewable and completed product components that support empiricism at the end of Sprint. Product incremental is a step toward a vision or goal. Whether or not the product owner decides to release it, the product increment must be available and able to meet the business requirements to accomplish the delivery plan.

2. Managing Your Scrum Journey with ZenTao：

ZenTaoproject management software provides software life cycle project management solutions, designed based on agile and CMMI management concepts and completely covers the core project management process.

Four management frameworks: Project, Product, Program, and Execution.

Four key concepts:Story, Task, Bug, Case.

So the ZenTao includes the 3 scrum artifacts ,3 scrum roles,5 scrum event.

Advantages of ZenTao

Zen Tao subdivides dozens of concepts, and each concept has a table. Different processes and operations can represent different concepts. Support for processes can be more diverse and personalized. The post-data processing is also transparent.
ZenTao provides all features in a complete product from start to finish. Provide a unified navigation system, user experience, interaction, and seamless connection of processes.
ZenTao has insisted on open source since the beginning. Open source can be said to be the business model of Zen Tao. Acquire users by open source and customers by services and features.

When creating a product backlog and sprint backlog, it’s crucial to have the right tools to organize, prioritize and assign all those tasks. ZenTao is a cloud-based project management software that has a real-time dashboard to track the progress of the project and offers a robust online platform with kanban boards for teams to collaborate during sprints. Try it today and see for yourself with this free 30-day trial！