1. An overview of the

Scrum is a framework for organizing and managing work. The Scrum framework is based on a set of values, principles, and practices to which organizations can add specific implementations of the relevant engineering practices and specific approaches to implementing Scrum practices.

Scrum is a refreshing framework, simple, people-oriented, and based on eight values: honesty, openness, courage, respect, focus, trust, empowerment, and collaboration.

Scrum practices are embodied in specific roles, activities, artifacts, and related rules.

2. The Scrum roles

A Scrum development effort consists of one or more Scrum teams, each consisting of three Scrum roles: Product Owner, Scrum Master, and Development Team.

The product owner is responsible for deciding what to develop and in what order. The Scrum Master is responsible for guiding the team to establish and follow its own process on the common Scrum framework. The development team is responsible for determining how to deliver the product required by the product owner.

2.1 Product Owner

The product owner is an authorized product leadership center. The TA is the only person who has the authority to decide which features to build and in what order. The product owner maintains a clear vision of what the Scrum team is trying to achieve and communicates it to each participant. The identity of the product owner determines that the TA is fully responsible for the solution being developed or maintained.

The products in question can be external products or internal applications. The product owner is also responsible for ensuring that the highest value work is always done, which may include more technical work. To ensure that the development team quickly builds the product that the product owner needs, the product owner actively works with the Scrum Master and the development team to answer the questions that the Scrum Master and the development team ask in a timely manner.

2.2 the Scrum Master

The Scrum Master helps each participant understand and embrace Scrum’s values, principles, and practices. The TA acts as a coach and plays an instructional role in the process, helping the Scrum team and others in the organization to develop appropriate high performance, organization-specific Scrum practices. At the same time, when adopting Scrum, there may be a challenging change management process that the Scrum Master helps the organization adapt to.

As a facilitator, the Scrum Master helps the team solve problems and improve the use of Scrum. They are also responsible for protecting the team from outside interference, providing leadership and removing barriers to team productivity. The Scrum Master has no authority over the team and this role is different from traditional roles such as project manager or development manager. A Scrum Master is a leader, not a manager.

2.3 Development Team

Traditional software development approaches address various types of positions, such as architects, programmers, testers, database administrators, and interface designers. Scrum defines the development team role, which is a diverse cross-functional team of people in several positions responsible for designing, building, and testing a product.

The development team organizes itself to determine the best way to achieve the goals set by the product owner. Development teams are typically five to nine people, and the team members as a whole must have a variety of skills to build high-quality, working software.

Scrum activities and artifacts

The Scrum framework is shown in the figure below, starting at the left and following the largest circular arrow, called a sprint.

The product owner establishes the product vision (the big cube in the figure), which is broken down into a set of features and collected into a product list through the sorting activity, and the items in the list are prioritized.

Sprints are represented by the largest circular arrow in the center of the diagram. The items in the product list may not be developed in a short sprint by the development team. Therefore, at the beginning of each sprint, the development team must identify a subset of the Product Backlog items that they believe they can complete, an activity known as sprint planning.

To be confident that the development team’s commitment is reasonable and appropriate, team members create a second list during the sprint planning session, called the Sprint list. The sprint list is a set of detailed tasks that describe how the team plans to design, build, integrate, and test a subset of features selected from the product list in this particular sprint.

Next comes the sprint execution, where the development team performs the tasks necessary to implement the selected features. Each day during the sprint, team members synchronize, review, and adjust plans to help manage the workflow through activities such as daily meetings. At the end of the sprint, the team produces a potentially releasable product increment that represents some, but not all, of the product owner’s vision.

The Scrum team performs two “review and adjust” activities at the end of the sprint. The first is called a sprint review, where stakeholders and the Scrum team look at the product being built. The second activity is called the sprint Review, in which the Scrum team examines the Scrum process used to build the product. The result of these activities may be an adaptive adjustment to the product list or part of the team development process.

At this point, the Scrum sprint cycle is repeated, with the team starting again to identify the next most important PBI(product list items) that can be completed. After the right amount of sprints, the product owner’s vision is implemented and the solution is released.

3.1 Product List

When using Scrum, we always do the most valuable work first. The product owner is ultimately responsible for determining and managing the order of work, with input from other Scrum team members and stakeholders, and communicating it to others in the form of a prioritized list of products. When developing a new product, PBI is initially a feature that needs to be developed to meet the product owner’s vision. For a product under development, the product list may also include new features, changes to existing features, defects to be fixed, and technical improvements.

The product owner collaborates with internal and external stakeholders to collect and define the PBI. Next, ensure that the PBI is placed in the correct order (using factors such as value, cost, knowledge, and risk) so that the high value items appear at the top of the product list and the low value items appear at the bottom. The product list is an evolving artifact. Items can be added, removed, or modified as the business environment changes or as the Scrum team learns more about the product (feedback on the software from each sprint).

3.2 the sprint

In Scrum, work takes place in iterations or cycles of no more than a month, which are called sprints. Each sprint should create something of clear value to the customer or user.

Sprints are time-limited, always have fixed start and end dates, and generally the duration of sprints should be equal. A new sprint starts immediately after the previous one. There is usually no room for changing goals or changing people within a range during a sprint, but sometimes business requirements prevent us from following this rule.

3.3 Make a sprint plan

A product list may represent weeks or months of work that cannot be completed in a short sprint. To determine the final subset of PBI to build for the next sprint, the product owner, development team, and Scrum Master need to do sprint planning.

During sprint planning, the product owner and the development team agree on what the current sprint aims to achieve. To this end, the development team reviews the product list to identify the high-priority items that can realistically be completed in the current sprint while working at a sustainable pace, which is a pace that the development team can easily maintain over a long period of time.

To gain confidence in getting the job done, many development teams break down each feature that needs to be done into a set of tasks. This set of tasks and their associated PBI make up the second list, called the Sprint list. The development team gives an estimate (usually in hours) of the amount of work required to complete each task. Breaking PBI into tasks is a form of design and a just-in-time feature completion plan.

3.4 Sprint Execution

After the Scrum team completes the sprint plan and agrees on the next sprint, the development team, under the guidance of the Scrum Master, performs all the task-level work needed to complete the feature. By “done,” I mean a high degree of confidence that all the work needed to produce a high-quality feature has been done.

No one tells the development team in what order and how to perform task-level work during the time it takes to complete a sprint list. Instead, team members define their task-level work, and then self-organize in the way they think best to achieve their sprint goals.

3.5 Daily Meetings

Each day during the sprint, ideally at the same time each day, the development team will have a daily meeting for a limited time (no more than 15 minutes). This inspection and adjustment activity is also known as the daily standing meeting because it keeps the meeting short and to the point.

A common practice in holding a daily meeting is for the Scrum Master to ensure that the meeting runs smoothly, with each team member taking turns answering three questions to keep the rest of the team informed.

  • What have I accomplished since the last daily meeting?
  • What do I plan to do before the next daily meeting?
  • What is keeping me from making progress?

By answering these questions, everyone can see the big picture, what’s going on, how we’re progressing toward our sprint goals, whether we need to change the plan for the day, and what issues need to be addressed. Daily meetings are essential to help the team manage a fast and flexible workflow within a sprint.

The daily routine is not for solving problems. Instead, many teams choose to postpone discussion of issues until after the daily meeting with a small group of people who are interested. The daily meeting is also not a status meeting in the traditional sense, especially not one called by the project manager to update the status of the project. However, a daily meeting might also be helpful for development team members to communicate the status of sprint list items. The daily meeting is primarily an activity to review, synchronize, and adapt daily plans to help self-organizing teams do their work better.

3.6 complete

In Scrum, we refer to sprint results as potential deliverables increments, meaning that everything the Scrum team promised to do is done, according to the agreed definition of “done.” This definition clearly states the need to have confidence in ensuring that the work done is of high quality and potentially releasable. For example, when developing software, the minimum definition of “done” is that a complete product function should be produced, designed, built, integrated, tested, and documented.

One of the most radical definitions of “done” is the ability to determine what to build for internal and external customers in each sprint when the business wants to deliver (or deploy, or release).

To be clear, potentially deliverable does not mean that what is built must actually be delivered. Delivery is a business decision, often influenced by other factors. Potential deliverables are best understood as the confidence to hedge against the actual product being built, meaning that if the business wants to deliver, we don’t need to do other important work, such as important testing and integration, until we deliver this sprint result.

3.7 Sprint Review

The sprint review activity is to examine and fine-tune the product being built. One of the important aspects of this activity is to have conversations among participants, including the Scrum team, stakeholders, sponsors, customers, and other interested members of the team. The focus of the conversation was to put the features just finished in the context of the overall development effort. Each participant has a clear understanding of the current situation and an opportunity to guide the next development steps to ensure that the most appropriate solution is produced.

A successful sprint review meeting facilitates a full exchange of information. Non-scrum team members can keep up with development efforts and help guide development. At the same time, when working with the business unit to deliver a product that meets the needs of the customer or user, receiving frequent feedback enables the Scrum team to further understand the business and market of the product. Therefore, the sprint review is a pre-arranged inspection and adjustment activity. In practice, non-Scrum team members can conduct feature reviews and provide feedback between sprints to help the Scrum team better achieve sprint goals.

3.8 Sprint Review

Sprint review occurs after the sprint review and before the next sprint plan. Sprint review is the time to review and adjust the product, while sprint review is the time to review and adjust the process. During sprint reviews, the development team, Scrum Master, and product owner get together to discuss what works and what doesn’t in Scrum and its related technical practices. The focus is on the continuous process improvement necessary to help a good Scrum team grow into a great team. At the end of the sprint review, the Scrum team should identify the right number of process improvements and commit to adopting them in the next sprint.

After completing the sprint review, the sprint process is repeated again, beginning with the next sprint planning meeting, which is held to identify the highest value work that the current team must focus on.

4. The conclusion

During the Spring Festival things are relatively more, people are also relatively lazy, did not adhere to the week more blog, guilty. In addition, this blog is mainly from the book The Essence of Scrum, and with so many masters out there, it sometimes feels like blogging doesn’t make sense, and no amount of hard work can keep up with it.

The next three months will be even busier, with daily management communication for new project development, Scrum Master and PMP training, and unpredictable other chores coming up. I suddenly feel it is necessary to further improve my time management concept and level, so that I can handle it calmly and welcome the future with a smile.

Reread The 7 Habits of Highly Effective People and try to find inspiration in times of confusion. There is no limit to how much you can learn.