Several meetings in scrum management and our practices

According to the first chapter of scrum in action, we can see several meetings below.

Release Planning

The product owner is responsible for the release planning meeting. The goal of this meeting is to specify a product development cycle consisting of several release, each of which must specify the delivery schedule.

For example, there should be a release plan similar to the following table at the end of the meeting:

Some procedures and methods are required to obtain the table above.

Sprint Planning

The meeting is divided into two phases:

Stage 1: Determine the requirement

The product owner introduces the story to be implemented by the sprint to the entire team, selects and adjusts the story based on the feedback from the team, sorts the priority of the backlog by the product owner, and selects the appropriate story.

The description template of story can be referred to below for a suggestion in the redmine backlog community:

The user story template. Proposals: * As a [type of user], I want [some goal] so that [some reason]. * [type of user] should be able to [some action]. * [some feature name]. * [some action] should lead to [some result].

The story must be clearly defined so that the product owner can perform the acceptance test. Only through the acceptance test can the product owner mark the story status as done.

The second stage determines how to implement the requirements

The development team leads the meeting and breaks down tasks from the story of the first stage. it takes several hours to jointly evaluate each task, such as the definition of task completion, technical details involved, and delivery results. Then decide who will take this task and who is reviewer.

Here is a commonly used task template. For example

Task Name: register account

Detail: user can register account himself, front-end page validates the input, back-end (rest API) Save the new account into storage (MongoDB replica-set ), send email to user if operation succeeds (we can write more words to define it very clear, it's just one simple example)

Result: Codes, test codes (over 70% coverage), in Ci

Working hours: 24

Owner: Mark

Reviewer: Dean Chen

Software systems can be used for support. For example, gitlab can also play an important auxiliary role when we adopt icescrum.

The reviewer is set here, which means that you do not wait for the meeting. When the task owner deems that the task has been completed, the reviewer can be notified to perform the check. A good system can record the comments of reviewer.

Daily scrum

The development team holds a stand-up daily meeting with the goal of short and effective communication. View the burn up or burn down graph every day to check the overall progress of the project. In practice, we can also discuss technical difficulties and unexpected situations. This is a daily evaluation of the sprint planning meeting results. Strictly speaking, you cannot modify, add, or reduce story and tasks that have been set. If modification is required, the product owner must agree with the team, but proceed with caution. If you do this frequently, there will be no plans at all. It has become a common practice for Chinese companies to work overtime to cope with demand changes.

Sprint Review

The product owner and the development team participate in the review meeting before the end of the sprint. The meeting process is as follows:

1. First, we will discuss the story and tasks that have been completed, focusing on the story layer.

2. Want the product owner to demonstrate the finished story

3. The product owner can introduce product requirements and market changes to prepare for the next sprint.

The following points are from my boss moxie:

1. Each sprint review is an internal product release. Therefore, introducing and demonstrating the progress made by the team on the product is the main content, rather than being discussed in specific tasks. Every developer is not required to demonstrate their tasks in turn.

2. for incomplete story and tasks, you need to carefully discuss the causes and find lessons learned.

Whether the team is not given a margin because of the too many targets. We usually take a discount on the target workload as the actual workload,

Whether the technical problem is overestimated or underestimated. For example, a series of technical solutions are introduced to an unexpected user experience problem. A Maven upgrade causes incompatibility of plugin.

Sprint impact spective

The purpose of the development team to hold the sprint review meeting and before the next sprint planning meeting is:

Summarize the lessons learned and propose the areas for improvement in the subsequent sprint.

At this stage, each developer can take turns to elaborate his or her views and follow the process below:

1. What have you done in last sprint?

This part of content can be simple and fast, because in practice, every task is regarded as ended only after being reviewed.

2. What unsolved problems have you found?

This part of valid content will be added to the backlog.

3. Give you suggestions about process, technique.

This part of valid content will also be added to the backlog.

I carefully reviewed the knowledge in the book and found the corresponding English terms, because in our office environment that advocates English, everyone should start a scrum meeting in English, the term is not in English. Well written, good translation, that is, the English term is missing.

At the same time, I also added a lot of practical experience and thanked csdn for its reading activity. It is very helpful to me.