[Best practices] In the agile scrum software development model, how do we start a sprint planning meeting?

In the agile development framework of scrum, the most important part is the Sprint plan meeting. If the meeting fails, the whole sprint will make the scrum team suffer and it is difficult to complete the initial sprint goal. After several attempts, we finally found our own model. These methods and principles are the best for us. Based on our own knowledge and our own project scenarios, we may not try them out for other teams.

--- Agile genie

• Just like any other meeting, determine the meeting schedule

The Sprint scheduled meeting must be based on time-boxed and must end within the specified time, just like a sprint.

Our schedule is generally like this.

Agenda:

Part I: product backlog review [product owner, scrum team]

Time: 2 hours

1) Enrich product backlog (60 minutes)

2) re-prioritize product backlog items (10 minutes)

Break (10 minutes)

3) set sprint goal (20 minutes)

4) Select Product backlogs to sprint (20 minutes)

Part II: Sprint planning [scrum team]

Time: 3-4 hours

1) Work Breakdown by two groups. (60 minutes)

Break (10 minutes)

2) Agree with the definition of "done" for each task with estimation (20 minutes)

3) Critical Path Analysis (20 minutes)

4) resource plan (20 minutes)

Break (10 minutes)

5) Find owner for each task. (40 minutes)

6) risk/dependecy analysis (20 minutes)

7) AOB

• The Sprint plan meeting must be completed within one full day.

The day when the Sprint plan meeting starts, that is, the day when the sprint starts. If the sprint planning meeting is going to take over two days, it's not a good thing. Your burndown Char will be as ugly as ours. Because we started 4 hours in the afternoon of the previous day and 3 hours in the morning of the next day to refine the task...

• Estimation of task workload using Delphi Method

When the task is refined, the estimation of each person is different. When there is a difference, the dephi estimation method is used. If the maximum estimation value differs by more than half of the minimum estimation value, to see why there are so many differences between the two. After understanding, re-estimate

• PM must be inSprint plan MEETINGThe expected working hours of sprint participants are provided before.

According to our historical statistics, our input rate is basically around 75%. For example, if one person is 8 hours at work, he spends about 6 hours on the project. If the sprint cycle takes 15 working days, the employee may take 2 days off and participate in training for 1 day, the expected work time he can invest is 6 * (15-2-1) = 78 hours. In this way, the number of "hours" in this sprint will be calculated in advance. In a sprint planning meeting, when selecting and refining a sprint task, you can avoid the problem of insufficient tasks or committing too many tasks by referring to the total expected working hours. At the same time, we also remind everyone not to over-commit when receiving the task.

• To improve the efficiency of task refinement, the team is divided into two groups.
  

At first, I opened the projector and threw everything in scrumworks to the screen. As you said, I was busy typing, but not everyone can concentrate on it... Now let's look at it. This method is really stupid! When there are few team members, this method is okay in the first few sprints when you are still interested.

When there are more than 6 team members, the problem arises. First, when we discuss a problem, someone will always ask, what did you say just now? Apparently, he is distracted... In addition, when there are many people, the same task is refined. Even if the Delphi method is used, the communication cost is very high and it takes a lot of time.

Divide the team into two groups to refine the tasks. When refining, the projector is no longer used, but the content in the sprint backlog is posted on the wall in a large part. Everyone is standing in front of the wall and carrying the Chronicle to refine and estimate it directly. After both groups are completed, check each other's details about the task, resolve the dispute, and clarify the vague points. In this way, everyone's enthusiasm will be mobilized, with a high degree of participation and high efficiency.

• Define the task "done" carefully!
  

This is a self-evident question.

• Although scrum is adopted, traditional risk/dependency analysis should not be discarded.

Even if the GATT diagram is no longer used, the analysis of risk/dependency before the Sprint plan meeting is over will help us find some problems by re-adjusting the task priority, this ensures the success of the sprint.

• The product owner must participate.

If you cannot participate, you must specify an authorized proxy. Otherwise, do not start a sprint scheduled meeting.

• The Sprint goal must be concise and prominent. The selected sprint backlog items must be strongly cohesive and loosely coupled.

In this way, everyone can be free from or less affected by external interference, with a clear goal.

• Give the sprint a good name.