Agile development-Scrum practice

Recently, I organized my previous scrum documents into a document. In the following team and project development, I introduced some practices of scrum according to the project, improve the collaboration capability and project delivery quality among team members.

　　References:

• Easy scrum journey-agile development story and agile invincible
• Scrum and XP in smoke
• Martian agile development manual
• Scrum-checklists
• Wikipedia-http://zh.wikipedia.org/wiki/Scrum

　　Scrum tools

• Zentao
• JIRA + greenhopper

　　Roles in scrum

Scrum master-project owner and Project Manager

It protects the team from external interference and is the leader and promoter of the team. It is responsible for improving the efficiency of the scrum team and controlling the "Inspection and adaptation" cycle process in scrum. Working with the product owner to maximize investment output, he ensures that all stakeholders can understand agile and respect agile ideas.

Team-all-functional teams including developers, testers, art designers, and DBAs

The team is responsible for product delivery and quality. The team works with all persons who propose product requirements, including customers and end users, and jointly creates product backlogs. The team should create a function design and test the backlog entries to deliver the product according to the consensus of everyone.

Product owner-product owner, product manager, and operation personnel

Drive the project from the business perspective, disseminate the clear vision of the product, and define its main features. The main responsibility of the product owner is to ensure that the team only develops the most important backlog entries for the Organization and helps the team to complete their work in the sprint without interfering with the team members, and quickly provide all the information required by the team.

User-end users, operators, and system users

Many may become end users, such as marketing personnel, real end users, the best field experts, or information consultants hired for their expertise. End users define products based on their business knowledge, inform the team of their expectations, and make a request.

Manager-management, investors

The management should build a good environment for the scrum team to ensure that the team can do well and, if necessary, they will reorganize the structure and guiding principles with the scrum master.

Customer: customers, system users, and operators

The customer is the person who puts forward product requirements for the scrum team. She signs a contract with the Organization to develop the product. Generally, these are senior management personnel in the organization responsible for purchasing software development capabilities from external software development companies. The customer is the person who approves the project budget for internal products.

　　Outputs in scrum

Product backlog -- the backlog to be developed and the backlog of tasks.

The product backlog includes all the content to be delivered. The content is arranged according to the value order of the business requirements. The priority of each backlog can be adjusted and the requirements can be increased or decreased, therefore, the product backlog will continue to drive maintenance based on the increasing number of products.

Sprint backlog-Sprint refers to the iteration cycle, which is usually one to six weeks.

Before the sprint starts, define the "sprint backlog" to be discussed in this sprint, and generate the "defined product backlog" to be completed in this sprint ".

Product Backlog defined

The outcome of the sprint planning meeting, which defines the workload accepted by the Team and will remain unchanged throughout the sprint.

User story and task-user stories and tasks

Use user story to describe projects in sprint backlog. User story is a brief description of a function module of the system from the user's perspective. A user story describes a small function in the project, and what effect the function will produce after it is completed, or what value it can create for the customer. The size and complexity of a user story should be appropriate in a sprint. If the user story is too large, the development may span several sprints. In this case, the user story should be decomposed.

To complete each story in a timely and efficient manner, the scrum team splits each story into several tasks. It is recommended that the time of each task be less than 8 hours and be sure to be completed within one working day. If the time of the task exceeds 8 hours, it indicates that there is a problem with the division of the task. Pay special attention to it.

Obstacle backlog-problem list, backlog of pending transactions.

Lists All internal and team-related issues that impede the project progress. The SCRUM master needs to ensure that all problems in the backlog have been assigned and can be solved.

　　General meeting rules

Basic Requirements

• Each meeting must start and end on time.
• Each meeting is open to everyone.

Preparations

• Invite all those who must attend the meeting in advance to give them time to prepare.
• Send the outline of the meeting with the meeting objectives and intentions.
• All resources required to book a meeting: Room, projector, wall chart, host equipment, and other things required for the meeting.
• A reminder will be sent 24 hours before the meeting.
• Prepare a wall chart with meeting rules.

Conference promotion

• During the discussion, the Conference promoter must be present. He cannot participate in a specific discussion, but he needs to pay attention to the discussion process. If the discussion participants lose focus, he will also take the discussion back to the formal level.
• The promoter displays the goals and intentions of the meeting.
• When necessary, the promoter can agree on a written meeting record.
• The promoter can record the team's opinions, or teach the team how to record their own documents, and the promoter may record the conversation on a wall chart to visualize the conversation.
• The promoters will close the meeting and give a brief review.

Meeting output

• You can use handwritten or wall chart instructions to record documents and take photos of the content on the whiteboard and the wall chart.
• The Meeting records must be clearly shared with everyone about the results.

　　Let the team sit together!

• Everyone is lazy and try to bring "Product owners" and "full-featured teams" together!
• Hear each other: Everyone can talk to each other without shouting or leaving their seats.
• View each other: everyone can see each other and see the task board. You don't have to be near enough to see the content, but at least you can see a rough picture.
• Isolation: if your entire team suddenly stood up and spontaneously formed a heated Design Discussion, no one outside the team would be disturbed, and vice versa.

　　Team building

• The best number of scrum teams is controlled in "5 ~ 9 "people.
• Full-time team: Development Team (backend developers, front-end developers, testers-3 ~ 8 persons), scrum master (Project Manager), product manager
• Part-time team members: artist, DBA, and O & M

　　Every Hitachi meeting (daily standup meeting)-we recommend that you start before work

Purpose

• The team schedules meetings, coordinates their daily activities, and reports and discusses obstacles encountered.
• The task board helps the team focus on daily activities. At this time, the task board and burn-out diagram should be updated.

Components

• Task board, instant sticker, marker
• Tip: scrummaster should not stand in front of the team or beside the task board, and should not create an atmosphere similar to that of teachers and students.

Basic Requirements

• Members: Team, scrum master
• The team members that cannot be present must be represented by their peers.
• Duration/Place: 15 minutes a day, the same time, the same place.
• Tip: when listening to others' speeches, team members should think about this question: "How can I help him do it faster ?"

Meeting output

• The teams clearly know each other's work and the latest work progress chart.
• Get the latest obstacle backlog"
• Get the latest "sprint backlog"

Meeting process

• The team gathers beside the story board and can be circled.
• Start from the first one on the left and explain his work to his team partners.
• The member then places the tasks on the task board in the correct column.
• If possible, the member can select a new task and place it in the "in progress" column.
• If the member encounters problems or obstacles, report them to the scrum master.
• Each team member repeats steps 2 to 5.

Each person has three questions:

• Which tasks have been completed during the last meeting? : Change the status of a task from "processing" to "completed. -- What has been done today?
• What tasks are you planning to accomplish before the next meeting? : If the task status is "pending", it is changed to "processing. If the task is not on the sprint backlog, add the task. If a task cannot be completed in one day, the task is subdivided into multiple tasks. If the task can be completed within one day, set the task status to "processing ". If the task status is "processing", check whether the task is blocked. -- What will we do tomorrow?
• What problems have hindered your development? : If there is a problem that hinders your development progress, add this obstacle to the barrier backlog. -- What problems have you encountered today?

Notes

• Don't be late
• Do not exceed the limit
• Do not discuss technical issues
• Do not change meeting topics
• Do not participate without preparation
• The SCRUM master should not move task cards for team members or update the burnout diagram for the team.
• The SCRUM master should not ask questions, and the team members should not report to the scrum master or management personnel.
• If you cannot attend the meeting, you must notify the team and ask a representative to attend the meeting.

　　Task Board

• The task board combines the selected product backlog and sprint backlog and displays them visually.
• The task board can only be maintained by the team, and developers can be differentiated by "instant Stickers" of different colors, or the name of the Acceptance task can be written in "instant Stickers.
• Use large whiteboards or software whenever possible.

The task board has four columns:

• Select the product backlog: Put the product backlog entries or stories that the team wants to start in the current sprint in the priority column.
• Task to be completed: to complete a story, you must complete some tasks. During a sprint planning meeting, or during the current sprint, collect new tasks to be completed for all specific backlog entries and put them in this column.
• Ongoing work: After a team member starts a task, he/she puts the cards corresponding to the task in the "ongoing work" column. From the previous daily scrum meeting, unfinished tasks are placed in this column and marked (usually red dot ). If a task takes more than one day in the "to be completed" column, try to divide the task into smaller parts and then place the new task in that column, remove the big task card to which it belongs. If a new task cannot be completed due to a certain obstacle, it will be marked with a red dot, and the scrum master will remember the next obstacle.
• Finished: After a task card is completed, the members who have completed the task put it in the "finished" column and start to select the next task card.

　　Burn down chart)

• The tracking progress should be completed by the team. the horizontal axis of the burnout chart indicates the total time of the entire sprint, and the vertical axis indicates all tasks in the sprint. The unit can be hours or days. In general, a burn-out chart is divided into a sprint burn-out chart and a release burn-out chart.
• The team updates the burnout chart every day.
• If the burned-out diagram is in the ascending state, or after the sprint starts for a period of time, the Y value in the Sprint's burned-out diagram is still the same as that in the beginning of the sprint, it indicates that there are too many story in the sprint, some story should be removed to ensure the smooth completion of the sprint. If the sprint burn-out chart drops quickly, for example, if the Y value is close to 0 when the sprint is just over half, it means that there are too few tasks assigned by the sprint and more tasks need to be added. At the sprint program meeting, if the team does not fully understand the tasks to be done, these two situations may occur. (Exercise team members' self-estimation time)
• A burn-out chart should be easy for the Team to update, and it should not be too complicated or difficult to maintain.

Release burnout diagram: record the progress of the entire scurm project. Its horizontal axis indicates all the sprints of this project, and the vertical axis indicates the unfinished work before each sprint starts, it can be measured in units (the number of story) and man-day.

　　Sprint planning meeting-Part 1 (morning)

Purpose

• The main purpose of this meeting is to understand in detail what end users need. The product development team can learn the real needs of end users from this meeting. At the end of the meeting, the Team will decide what they can deliver.
• Product owner prepares before the Meeting: Entry-based requirements (user stories), priority sorting, last 1 ~ The two functions that are most desired by iteration. Pre-meeting preparation is crucial to help product owners clarify their clues and avoid frequent changes, increases, or deletions during the iteration period.

Basic Requirements

• The iteration plan will be held on the first day of each iteration to select and estimate the work items of this iteration.
• Only a team member can determine how many backlog entries the team can receive in the current sprint.

Components:

• Estimated and sorted product backlog.
• La S, markers, scissors, glue, instant stickers, whiteboards, pencils, and crayons.
• Detailed contact information of the holiday schedule and important personnel.
• Participants: Team members, scrum master, and product owner

Duration: In a sprint, a weekly meeting takes 60 minutes and is held in the morning. In this way, the second part of the sprint planning meeting may be held on the same day.

Meeting output

• Select a product backlog entry.
• Requirements for each backlog entry.
• User Acceptance Test for each backlog entry.

Meeting process

• Start with the first product backlog entry (story.
• This article discusses the product backlog entry for further understanding.
• Analyze and clarify the User Acceptance Test.
• Find non-functional requirements (performance, stability ...)
• Locate the acceptance criteria.
• Determine the level to which the task needs to be completed.
• Get a clear understanding of all aspects of the backlog entries.
• Draw charts of deliverables, including flowcharts, UML diagrams, hand-drawn sketches, and screen UI design.
• Return to Step 1 and select the next backlog entry.

Process Check: Ask the team if they can quickly answer the following questions. Just give a brief answer: "Can we complete the first backlog entry in this sprint ?" If you can get a positive answer, continue to ask for the next backlog entry until the last backlog entry that has been analyzed. -- Next, take a rest. After the break, start the above process for the next backlog entry.

End Process:

• Set aside 20 minutes before the first part of the sprint planning meeting ends.
• Ask another question-this time it should be more serious and formal: "Can you complete the first backlog entry... the second one ,...?"
• If the team thinks they cannot accept more backlog entries, stop.
• Now is a very important step: to send the product owner away, everyone except the team and the scrum master will have to leave.
• When everyone else leaves, ask the team: "really -- do you believe you can complete this list ?"
• I hope the team can have a brief discussion to see how much work they think they can accomplish.
• Communicate the results with the product owner and end users.

Note: Do not change the size of backlog entries or estimate tasks.

　　Sprint planning meeting-Part 2 (afternoon)

Purpose

• The work of the Meeting is mainly designed. The product development team can complete the design work for the solution they want to implement. After the meeting, the team knows how to build the features they want to develop in the current sprint.

Basic Requirements

• Only the product development team can develop a solution. Architects or other people outside the team are invited to help the team.

Components:

• Persons who can help the team build solutions in the sprint, such as vendors or personnel from other teams.
• Select a product backlog entry.
• Wall Chart ......

Note: Do not estimate tasks or assign tasks.

Meeting output

• Application Design, architecture design diagram, and Related Charts
• Make sure the Team knows how to complete the task!

Meeting process

• Start with the first backlog entry.
• View the wall chart to make sure that you understand the customer's requirements correctly.
• This backlog entry is designed based on the following similar issues:
  • What interfaces do we need to compile?
  • What architecture do we need to create?
  • What tables do we need to update?
  • What components do we need to update or compile?
  • ......

When the team knows exactly how to develop this function, they can switch to the next backlog entry. In the last 10 minutes of the meeting, the team members used instant posts to write preliminary tasks. This helps team members know where to start the next task and place the tasks on the task board.

Duration: after the first part of the sprint planning meeting is completed, the meeting will be held. Lunch can be used as a longer break for two meetings. However, the first part of the sprint planning needs to be completed on the same day. In the sprint, the weekly meeting takes 60 minutes.

　　Estimate meeting-merge to sprint Part 2 meeting based on project conditions

Purpose

• To make a strategic plan, you need to know the size of each item in the backlog, which is necessary for version planning. If you want to know how much work the team can do in a sprint, this data is also necessary.
• Team members can know what will happen in the next stage of the project from the meeting.

Basic Requirements

• Only the team can make an estimation. The product owner (product owner) needs to be present to help determine whether some user stories can be split into smaller ones.

Components:

• The product owner schedules the order of product backlog based on the business value.
• Participants: Team, product owner, user, and scrum master

Note:

• Do not estimate the workload-only teams can do this.
• The product owner is not involved in the estimation.

Meeting process

• The prodcut owner shows the product backlog entries that she wants to estimate.
• The team uses planning poker to estimate backlog entries.
• If a backlog entry is too large and needs to be placed in the next or subsequent sprint, the team will divide the large backlog entry into several smaller backlog entries, estimate the use of planning poker for new backlog entries.
• Re-estimate the entries in the backlog that are not completed yet, but may be completed in the next three sprints.

Duration: The maximum meeting time is 90 minutes. If the sprint lasts longer than a week, it is appropriate to hold two estimation meetings for each sprint.

Meeting output

• The estimated product backlog.
• Smaller backlog entries.

　　Planning poker)

Procedure:

• Each person makes an independent dark card after estimation, and opens the card together with the password.
• The primary key is the primary key for the numeric value and the primary key for others to listen.
• After the discussion, open the cards again.
• Repeat the above process until the result is close.

FAQs

1. Why should tasks be assigned to groups rather than individuals?

A: I am afraid that I will not be able to say anything when I get a card wrong. Even if I don't do this function in the future, I am very familiar with this function.

2. Why not let the person who finally receives the task estimate by himself?

A: Because he probably chose the wrong implementation method because he does not know that a code is available or that a software is unavailable.

3. Why not let the master estimate that everyone should adopt it? Isn't it the most amazing?

A: The teacher's ideas are often incomprehensible to the disciples. For example, why do they go to the West to learn classics instead of staying in the daughter's country, A common estimation is a process that allows everyone to compare their own implementation methods with their masters.

　　Sprint Review Meeting-based on project needs

Purpose

• The SCRUM team shows the results of the work to the end users during the meeting. The team members hope to get feedback and create or change backlog entries.

Basic Requirements

• The Sprint review allows all participants to try new features presented by the Team.

Components

• Product increments that may be released are displayed by the team.

Meeting output

• Feedback from end users.
• The input of the barrier backlog.
• Team backlog input.
• Feedback from the team generates input for the product backlog.

Duration: 90 minutes at the end of the sprint.

Meeting process

• Product owner: Welcome to the sprint review meeting.
• The product owner reminds everyone about the purpose of this Sprint: the sprint goal and the story of the scrum team selecting development in this sprint.
• The product development team displays new features and allows end users to try new features.
• The SCRUM master promotes the meeting process.
• End user feedback will be recorded by the product owner and/or the scrum master.

Note:

• Do not show the product increments that cannot be released.
• The SCRUM master is not responsible for Displaying results.
• The team should not present it to the product owner.
• Sprint reflection meeting (reflected spective meetin)-based on project needs

Purpose

• The corresponding metaphor of the meeting: medical diagnosis! The goal is not to find a cure, but to find out what needs to be improved.

Components

• Participants: Team members, scrum master

Basic Requirements

• Learn from the past and guide the future.
• Improve team productivity.

Notes

• Do not involve management personnel in meetings.
• Do not discuss what is found outside the team.

Meeting output

• The input of the barrier backlog.
• Team backlog input.

Duration: 90 minutes, which starts several minutes after the sprint review.

Meeting process

• Prepare a message saying "What did you do well in the past ?" .
• Prepare a message saying "What improvements should be made ?" .
• Draw a timeline with the start and end dates.
• Each team member is assigned a stack of instant stickers.
• Start to review.
• Perform a security exercise.
• Collect facts: publish a pay-as-you-go post to form a timeline. Each team member (including the scrum master) writes an important event on each instant sticker.
• "What did you do well in the past ?" : The process of collecting facts is the same, but this time we need to put the current post on the prepared wall chart.
• Make a separation to distinguish between "What has done well in the past" and what will be produced next.
• "What improvements should be made ?" : Like "What has done well in the past.
• Now, you can group the post as follows:
• What can we do? Team backlog input.
• What are beyond our control? The input of the barrier backlog.
• Sort the two lists according to the opinions of the team members.
• Use these two lists as inputs for the first part of the next sprint Planning Meeting and the second part of the sprint planning meeting, and decide how to handle the findings at that time.

　　Two flowchart (Materials)

Agile development-Scrum practice