Scrum is often thought of as an agile development project management framework that describes a set of meetings, tools, and roles that work together to help teams organize and manage their work.
First, what is Scrum
Scrum is a framework that helps teams work together. Just as a football team (where its name comes from) trains for large competitions, Scrum encourages teams to learn from experience, approach problems in a self-organizing way, and reflect on their wins and losses for continuous improvement.
While we say that Scrum is most commonly used by software development teams, its principles and lessons can be used for a variety of teamwork, which is one of the reasons Scrum is so popular. Scrum is often thought of as an agile development project management framework that describes a set of meetings, tools, and roles that work together to help teams organize and manage their work.
Second, a commonly used agile development framework: Scrum
Scrum and Agile Development are often thought of as the same thing because Scrum focuses on continuous improvement, which is a core principle of Agile development.
However, Scrum is a framework for getting work done, and agile development is a mindset.
You can't really be "agile" with Scrum alone, because it requires a concerted effort from the entire team to change the way they think about delivering value to their customers.
However, you can use frameworks such as Scrum to help you start thinking about this approach and practice how to build agile workflow principles in your daily communication and work.
The Scrum Framework is an heuristic framework based on continuous learning and adjustment of volatility factors. It acknowledges that the team didn't know everything at the beginning of the project and continued to evolve by learning lessons. Scrum's structure is designed to help teams naturally adapt to changing conditions and user requirements, and reprioritize processes and shorter release cycles so your team can continually learn and improve.
Scrum Framework | Agile Coach
While Scrum is a structured framework, it's not completely rigid, and you can adapt its execution to your organization's needs. There is a lot of theory about how the Scrum team can succeed.
However, for more than a decade, in helping the PingCode Agile Development team get the job done, we've found that no matter which framework you choose, clear communication, transparency, and commitment to continuous improvement are always at the heart of the framework.
1. The three important roles that Scrum needs to succeed in
The Scrum team requires three specific roles: Product Ower, ScrumMaster, and Scrum Team. Because the Scrum team is cross-functional, in addition to developers, the development team includes testers, designers, user experience (UX) experts, and operations engineers.
Product Owner
Primarily responsible for building the right product, determining what the Scrum team delivers and explaining why it's doing the work. The Product Owner is a leader in products. They focus on understanding business, customer, and market requirements, and then prioritize the work that the engineering team needs to accomplish accordingly. An effective Product Owner should be able to:
- build and manage product backlogs.
- work closely with businesses and teams to ensure that everyone understands the work items in the product backlog.
- be clear on what features your team will provide next.
- determine when to release a product and tend to deliver it more frequently.
- the product owner doesn't have to be a product manager. the product owner is focused on ensuring that the development team brings the most value to the business. in addition, it is very important that the product owner is an individual. no development team needs mixed guidance from multiple product owners.
Scrum Master
Primarily responsible for helping everyone in the Product Owner and development team understand and embrace Scrum's values, principles, and practices. The Scrum Master is the leader in Scrum on his team.
They are responsible for training teams, product owners, and the business on the Scrum process and finding ways to fine-tune their practices in this area. An effective Scrum lead should have a deep understanding of what the team is doing and can assist the team in optimizing its transparency and delivery processes. As the primary facilitator, this role is responsible for scheduling the resources (human and material) required for sprint planning, daily short meetings, sprint reviews, and sprint reviews.
Scrum team
Responsible for building products the right way and performing specific work tasks. Scrum teams are the performers of specific work, typically between 5 and 7 members. One way to determine the size of the team is the famous "two pizza principles" proposed by Amazon CEO Jeff Bezos (the team should be small enough to share two pizzas). Team members have different skills and are tempering each other, so no one is going to be a bottleneck in delivering work.
A strong Scrum team follows the principle of self-organization and takes a clear "we" stance when approaching projects. All members of the team help each other to ensure a successful sprint.
Scrum teams can advance the plan for each sprint. They use their historical speed as a guide, predicting the amount of work they think they can accomplish during the iteration. Keeping iteration lengths fixed provides development teams with important feedback on their estimation and delivery processes, allowing them to make more accurate predictions over time.
2. Scrum workpiece
Artifacts are things we accomplish, like tools to solve problems. In Scrum, the three artifacts are the product to-do, the Sprint to-do, and the incremental change in the definition of "completed."
They are three constants in the Scrum team that we constantly revisit and invest extra time in improving.
Product Backlog
the product backlog collection, the user story collection of the entire product, these user stories can come from party a's customers, end users, po's own understanding of the product, r & d team, etc.
essentially, this is the team's "to-do" list. product owners constantly rethink, reprioritize, and maintain product backlogs, as we learn more or as the market changes, the items on the list may no longer be relevant or may otherwise resolve issues.
Product Goal: Product Goal
Product Goal describes the future state of the product and can serve as a goal for Scrum Team's planning. Product Goal 在 Product Backlog ä¸。 The rest of the Product Backlog emerged to define what "do" would implement the Product Goal.
A product is a vehicle for delivering value, with clear boundaries, known stakeholders, and well-defined users or customers. A product can be a service, a physical product, or something more abstract. Product Goal is a long-term goal of scrum team. They must first achieve (or abandon) one goal before moving on to the next.
Sprint Backlog
Sprint to-do list, a list of user stories within the sprint target phase. These user stories come from Product Backlog, and before each sprint, the PO puts the highest priority user stories into iterations based on delivery value.
before each sprint, in the sprint planning meeting (which we'll discuss later), the team selects the project to be worked on for the sprint from the product backlog. sprint to-dos may be more flexible and can be developed during sprints. however, the basic sprint goals (what the team hopes to achieve by the current sprint) cannot be affected.
Sprint: Sprint Goal
Sprint Goal is a single target for Sprint. While Sprint Goal is a commitment from Developers, it provides flexibility in the exact aspects of the work required to achieve that goal. Sprint Goal also creates coherence and focus points that encourage Scrum Teams to work together rather than acting alone.
Sprint Goal is determined in the Sprint Planning event and then added to the Sprint Backlog. When Dewers worked during Sprint, they took Sprint Goal to heart. If the work needed to be done is different from what was expected, they will work with the Product Owner to negotiate the scope of the Sprint Backlog without affecting sprint goal.
increment
The increment is the sum of all product backlog items completed by a sprint, and the sum of the value of the increments generated by all previous sprints. At the end of the Sprint, the new increment must be "done," meaning it must be available and meet the criteria defined as "done" by the Scrum team.
when completing the above three artifacts, the team can choose to define many variants, because it is best to maintain an open attitude to workpiece maintenance. for example, "completed" and "story point" redefinition can better improve efficiency and quality, then you can completely define according to the needs.
You should work with the Scrum framework as agilely as you would a product, spend some necessary time checking the progress of transactions (whether through a tool like PingCode or something else), and make adjustments if necessary, rather than forcing yourself to do something just for the sake of consistency.
3. Scrum ceremony
Some of the better-known components of the Scrum framework include a series of meetings that the Scrum team holds on a regular basis. In these rituals, we can see the biggest differences between teams.
for example, some teams find it tedious and repetitive to perform all of these rituals, while others use these rituals as a necessary means of registration. our advice is to use all the rituals in both sprint stages and then see how they work. you can then take a quick retrospective to see what adjustments might need to be made.
Here is a list of all the important ceremonies that the Scrum team may attend:
Backlog Grooming Meeting
sometimes referred to as to-do grooming, it's the product owner. the product owner's primary job is to assist in the realization of the product vision and to keep an eye on the market and customers. as a result, customers can maintain this list based on feedback from users and the development team to assist in prioritizing and keeping it clean while being prepared to work at any given time.
Sprint planning meeting
The entire development team plans the work to be performed during the current sprint (scope) during this meeting. The meeting was moderated by Scrum Master, during which the team decided on sprint goals. You can then add a purpose-specific story from the product to-do to the sprint. These stories should always be consistent with the goal, and the Scrum team should also promise to complete during the sprint. At the end of the planning meeting, each Scrum member needs to be clear about what can be delivered during the sprint and how incremental changes will be delivered.
Sprint
A sprint is the actual time period in which the Scrum team works together to complete the increment. Two weeks is a fairly typical sprint duration, although some teams find it easier to determine the range in a week, or it is easier to provide valuable incremental variations in a month.
But Dave West, a well-known abroad agile coach, suggests that the more complex the work, the more unknowns there are, and the shorter the sprint should be. But in fact, it's up to the team, and if it doesn't work, the team can make changes too! All events, from planning to retrospectives, occur during the sprint.
once a specific time interval for a sprint has been determined, it must be consistent throughout the development period. this helps the team learn lessons and apply those insights to future sprints.
Scrum Daily Standup Meeting
this is a very short regular meeting held at the same time and place every day (usually in the morning) to ensure that the meeting is concise and clear. a lot of teams try to complete the meeting in 15 minutes, but that's just a reference. this meeting, also known as the "short daily meeting", emphasizes the need for expeditious meetings.
Daily Scrum is designed to keep every member of your team in sync, work together toward sprint goals, and plan for the next 24 hours. You can talk about the problems you're having with your sprint goals or solving any obstacles in your daily short meetings.
one of the common ways to hold a short daily meeting is to have each team member answer three questions as they achieve their sprint goals:
- what did i do yesterday?
- what am i going to do today?
- are there any obstacles?
however, we found that the meeting would soon turn into a schedule for everyone to state yesterday and the next day. the rationale behind the daily meeting is that it distracts the attention of the daily meeting so that the team can focus on work for the rest of the day.
therefore, if it unfortunately becomes a daily calendar reading meeting, it should be decisive to change in order to innovate.
Sprint Review Meeting
at the end of the sprint, the team gathers for an informal meeting to watch an incremental demo or check the increment. the development team presents stakeholders and team members to to-dos that are currently in the "completed" state to solicit their feedback.
although increments are released in most cases, the product owner can still decide whether to publish increments. this review meeting is also the time for the product owner to reprocess the product backlog against the current sprint, which can provide information for the next sprint planning meeting.
for a one-month sprint, consider limiting your sprint review time to a maximum of four hours.
Sprint Retrospective Meeting
a time when teams come together to record and discuss sprints, projects, people or relationships, tools, and even what works and what doesn't in certain rituals.
the idea was to create a place where the team could focus on what was going well and what needed to be improved, rather than what went wrong.
No comments:
Post a Comment