Scrum Learning Notes

1. Overview

Scrum is a development framework for cross-functional teams to develop products or projects in an iterative, incremental way .

It organizes development into a work cycle known as Sprint. Each of these iterations is not more than 4 weeks (the most common is two weeks), and is not intermittent in succession. Sprints are limited by the time box, and they end on a specific date and never extend, regardless of whether the work is completed or not. The duration of a sprint is usually selected by the scrum team, and is used for all of their sprints until the team is able to improve and can use a shorter period.

At the beginning of each sprint, the cross-functional team (approximately 7 members) selects items from the prioritized list (customer requirements). Teams agree on what set of goals they can deliver at the end of the sprint, which should be tangible and can be really "done".

Not to add new things during the sprint, scrum accepts changes at the next sprint, with only a short , clear, relatively fixed target in the current sprint cycle. The team takes a short meeting every day to test the work process and adjusts the next steps to ensure that the remaining work is completed.

At the end of the sprint, the team reviewed the sprint with the stakeholder and demonstrated the product being built. Team members get feedback that can be combined into the next sprint. Scrum emphasizes the production of a work product that is really "done" at the end of the sprint. In the realm of software, a potentially deliverable system that has been integrated, fully tested, and has been generated for end-user documentation.

2. Main role2.1 Product Owner

• Determine the function of the product and be responsible for maintaining the product backlog.
• Determine the release date and release content of the product.
• Responsible for the return on Investment (ROI) of the product.
• Prioritize functions based on market value.
• Adjust features and prioritize features before each sprint starts.
• Accept or reject the work of the development team at the end of the sprint.

The product owner is a person, not a committee. Some committees may make recommendations to product owners or influence his decisions, but the product owner must be persuaded to change the priority of an item.

Companies that implement scrum may find ways to influence their priorities and needs.

In order to ensure the success of the product owner's work, all personnel in the enterprise must respect his decision. No one should ask the team to work in a different set of priorities, and the team will not be allowed to listen to anyone with threat-threatening instructions. Decisions made by the product owner need to be visualized through the product backlog content and priority. This visualization requires the product owner to go all out and make it a painstaking but worthwhile role.

2.2 Scrum Master

• Ensure that team resources are fully available and that they are all highly productive.
• Ensure good collaboration among roles and responsibilities.
• Solve the obstacles in team development.
• As a team and external interface, shielding the outside of the team members of the interference.
• Ensure the development process is planned, organize daily stations, Sprint planning meetings, sprint review meetings, and Sprint retrospectives.

Scrum Master needs to know what tasks have been completed, which tasks have been started, which new tasks have been discovered, and which estimates may have changed.

The Scrum Master needs to update the work done on a daily basis and how much of the Burndown chart (burndown chart) has not been completed, based on the above situation.

The Scrum Master must also carefully consider the number of tasks that are being developed at the same time, and work that needs to be minimized to achieve the benefits of lean productivity.

Scrum master needs to find obstacles and dependencies that hinder the team. They need to prioritize and track. Specify the plan to address these barriers according to the priority level. Some of these problems can be solved within the team, others are coordinated between the teams, and some have to be managed by the intervention of the management, or even some of the company's problems hinder the team to achieve their productivity. For example, a telecommunications company recently implemented scrum, but later found that only two issues were related to the scrum team, and that the rest of the company's issues required management attention.

Last but not least, scrum Master may notice that personal issues or conflicts need to be addressed in Scrum. These need to be clarified, or resolved through internal communication, or addressed to management and HR for assistance. Scrum Master must be careful to ensure that team resources are fully exploited and are all highly productive.

2.3 Team

1. Scrum team size controlled by 5-9 people

   • If the membership is less than 5 people, the communication is reduced and the productivity of the team decreases. More importantly, the team may be subject to skill limitations in the sprint, resulting in the inability to deliver a published product module.
   • If there are more than 9 members, there will be too much coordination and communication between the members.
   • Large teams create too much complexity and are not easy to experience process control.
   • For large projects, multiple small scrum teams can be used to solve communication coordination issues between teams through the scrum of scrums .

2. The scrum team is a cross-functional team

   • Team members must have the skills required to deliver product increments.
   • Team members often have expertise such as programming, quality control, business analysis, architecture, user interface design, or database design.
   • Without the concept of a title in the scrum team, everyone must do their best to complete the sprint goals.
   • Sub-teams that work in specific areas, such as testing or business analysis, are not allowed in the team .

3. The scrum team is self-organizing

   • No one, including Scrum master, has the right to prescribe how a team can translate a product backlog into a deliverable function increment, as determined by the team itself.
   • Each team member uses his or her expertise to solve the problems encountered. This synergy improves the overall efficiency of the team.
   • The composition of the team may change at the end of the sprint, and each change in team members will reduce the productivity gained through self-organization. Therefore, it is important to be cautious when changing team composition.

2.4 Users and stakeholders (customers, suppliers)3. Workpiece3.1 Product Backlog

• The Product Backlog list exists (and evolves) throughout the product's life cycle, which is the roadmap for the product.
• At any time, the product to-do list is the only, final generalization of the team's work in order of priority.
• There is only one product backlog list for a product, which means that the product owner has to take a holistic, prioritized decision to reflect the wishes of stakeholders, including the team.

The Product Backlog list includes different kinds of things :

• New customer features ("Enable all users to put books into the shopping Cart"),
• There are also major technical improvement goals (such as "using Java instead of C + + rewrite system"),
• There are also improvement goals (such as "accelerated testing"), research work ("Explore solutions to accelerate effective verification of credit cards"),
• There may also be a known flaw ("parsing and repairing the Order Processing script error"),
• If there are not many problems (if the system has many flaws, there will usually be a separate bug tracking system).

A good product to-do list to do :

• Suitable for thickness (detailed appropriately)

The top of the priority list is more precise and detailed than the lower-level items, because the former is developed first. For example, 10% of the top of the to-do list might contain very small and well-analyzed items, while the other 90% are less specific.

• Estimated (estimated)

The current release of the issue requires an estimate, and as you know more and the integration of new information, you should reconsider these estimates in each sprint. The team gives the product owner a workload estimate and a technical risk estimate for each item in the Product Backlog list. Product owners and other business stakeholders provide value information about the product's needs, which may include gains, reduced costs, business risks, importance to different stakeholders, and so on.

• Emergent (emergent)

To respond to learning and change, periodically comb the product backlog list . Each sprint may want to add, delete, modify, break down, or adjust the priority level of a matter. As a result, the product owner continually updates the product backlog to reflect changes in customer needs, new ideas or insights, changes in competition, technical hurdles, and so on.

• Rank priority (prioritized)

Items at the top of the product to-do list have the highest priority, or are ordered in 1-start order. In general, the highest priority matters should be the best value : High yield (business value) low cost (costs). Another incentive to prioritize something is to get rid of it early before a high-risk attack.

3.2 Sprint Backlog

The team creates a work list for each product backlog item, sometimes consisting of tasks that are broken down by the items in the product to-do list. Or when the items in the product to-do list are small and can be implemented in just a few hours, it's easy to make up a list of product backlog items.

4. Scrum Development process Events4.1 Sprint Planning Meeting

Usually divided into two parts :

1. About what to do

   • Participants: Product owner, team, ScrumMaster
   • Length: The number of hours in the time box is equal to the number of weeks in the sprint
   • Product owners and teams look at the high-priority items that the product owner is interested in achieving in this sprint in the product to-do list. Usually, these things should have been well analyzed in the previous sprint (the product to-do List grooming session) , so there are only a few questions that need to be clarified at the last minute. In this meeting, the product owner and team discuss the goal and context of these high-priority items in the product backlog, giving the team insight into the thinking of the product owner , focusing on understanding what the product owner wants and why it is needed.

2. About what to do

   • Participants: Team, ScrumMaster, product owner (not mandatory, but can be found to answer questions)
   • Length: The number of hours in the time box is equal to the number of weeks in the sprint
   • Focus on How to achieve the things that the team decides to start doing. The team expects how many things they can accomplish at the end of the sprint, starting with the top of the product backlog (in other words, starting with the highest priority for the product owner ), and then reviewing the items in turn. The following are key practices in scrum: The team determines how much work will be done, rather than being assigned to them by the product owner. Because the team is based on their own analysis and planning, this makes the expectations more reliable. Although the product owner has no control over how much work the team accepts, he understands that the items in the product to-do list are taken from the top, in other words, by taking the items that were important to him first. Teams can lobby for a lot of what's going on in the list, which usually happens when teams and product owners find something that's low-priority is easy and can be properly merged with high-priority items.

4.2 Product Backlog List Grooming

Overview : Split events, analyze events, re-estimate, and prioritize for future sprints.

participant : Team; If the product owner is an expert who can help with the details, he or she will be involved in the whole event, otherwise he can participate only in one part to set the direction or prioritize; other people who understand the needs and can give the team help; Scrum Master will instruct the team how to effectively open the meeting at the beginning of the session, otherwise he won't have to attend.

Duration: Usually no more than 10% of a sprint's working capacity for a team, but sometimes it takes longer to "have a lot of analytical work". For example, for a two-week sprint, it might take a day to comb.

4.3 Sprint Review Meeting

Overview : Demonstrate product increments and review and adjust for functional product increments at the meeting. It allows the product owner to understand the current situation of the product and the team (i.e., the review of the Sprint), and to let the team know the current situation of the product owner and the market.

participants : Team, product owner, ScrumMaster. The product owner can invite other appropriate stakeholders to participate.

Duration: The time box corresponds to one hours per week in the sprint.

4.4 Sprint Review Conference

Overview : Review and adapt to processes and environments.

participants : Team, ScrumMaster, product owner (not required). The team may invite other stakeholders who are not allowed to participate.

Duration: The time box is 45 minutes per week for the corresponding sprint.

4.5 Start the next sprint

After a sprint review, the product owner can update the product backlog list based on any new insights, such as adding new items, deleting obsolete items, or modifying existing items. The product owner is responsible for ensuring that these changes are reflected in the product backlog list.

5. Other5.1 Workload Estimation

Todo

5.2 Definition of "done"

Is all code check-in even if the story is done, or is it put in the test environment and verified by the integrated Test team?

This is important, and the product owner and team must agree that there is a consistent definition of "done".

5.3 Daily Meetings

Overview : Update information and reconcile among team members.

participants : The team must attend, the product owner is not required, scrummaster is usually present, but ensure that the team hosts the meeting themselves.

Duration: up to 15 minutes.

This is a time when self-organizing teams share their current work , and each team member reports three things to other members of the team one by one:

1. What has been done since the last meeting?
2. What work will be done before the next meeting?
3. What are the obstacles?

track progress during the 5.4 sprint

The team in scrum is self-managing and to do this, the team must know how well they are doing. Every day, team members update their estimates on the sprint backlog about how much work they will need to complete their current job. It is also common practice for someone to add up the remaining work and then draw a point on the Sprint Burndown chart . This figure shows a new estimate of the amount of work remaining for the team to complete each day. Ideally, this should be a downward slash, whose trajectory points to the last day of the sprint without the remaining work . So it is called Burndown chart .

6. Reference

1. Scrum Guide

Scrum Learning Notes