Finally, the last Scrum article, if the length of the previous article scared you. It doesn’t matter if you didn’t remember them, we’ll go back to them after today’s simple article. Of course, if you’re preparing for the PMI-ACP, try to memorize them.

The flow chart

First, of course, let’s start with the familiar flowchart that appears in every Scrum article.

In this figure, we see 353 from the previous article. Do you remember what it was?

Next, let’s look at how these practices work in this diagram.

Typical flow application scenarios

  1. The vision and ROI are presented by senior management or the client, and the PO is often involved in these discussions.

  2. The PO extracts what we need to do from the vision and ROI, which is our product backlog. This list is usually in the form of a user story about what we need to do. There will also be goals and epic stories. An epic is a higher and more abstract story, far from being able to be broken down into missions, but it can be broken down into smaller stories.

  3. With the product backlog in place and the PO prioritizing them, it was time to move on to the next step, which was a pre-sprint sprint planning meeting with the team.

  4. During the sprint planning meeting, the PO and the team determine what needs to be done and form a sprint backlog. The list of sprints to develop can be stories or smaller stories — tasks.

  5. With the sprints to develop list determined, the team is ready to start sprints, which are the two circles in the figure. The large circle represents the entire sprint cycle, usually 2-4 weeks. The circles represent the progress to be updated every 24 hours. Notice the little circle in the upper right corner? That’s where the daily station will be.

  6. The team conducts daily station meetings in small circles, that is, every 24 hours we need to know how the team is doing.

  7. At the top of the large circle, there is also a Product Backlog Relinement, where the team and PO make revisions to the Product Backlog at each sprint and in the sprint review meeting after the sprint. Also determine if the team has “met” our sprint goals.

  8. Finally, during the sprint review meeting, we summarized lessons learned and looked for ways to improve for the next iteration.

At this point, a Scrum-style sprint development process is over. Yi? Wrong ah? What is the Scrum Master doing? Stand on the side?

Scrum Master

Back to SM. This abbreviation actually has something to do with….

Earlier in the character introduction, we talked about what SM is a leader. He is a servant leader, and he has to participate in and be involved in all the steps above. He doesn’t do much concrete, though. When he finds that other people or things are interfering with the team, he needs to clear those obstacles. When he found the team atmosphere was not right, he used communication and emotional intelligence skills to solve the problems between team members. When he noticed an unexplained fluctuation in the burnout chart, he had to analyze the cause and find the problem.

Does SM need to understand technology and products? Yes, and the more you know, the better, but will he make it himself? No, absolutely not. SM can remind, can insinuate, can guide, but, don’t do it yourself. Trust your team, believe in their capabilities, and believe in the power of self-organization in Agile.

Being a good SM is the same as being a good traditional project manager. The only difference is that we don’t have to plan too much and give too many orders. From an Agile point of view, SM is the same as team and PO. It’s not about who orders who, it’s about communication. And the coach’s guiding responsibility is also achieved through communication.

conclusion

Are you kidding? This article is really very simple and very minimal. The rest is practice, or the same words, from the simplest practice. Scrum is different from XP, which is a complete software development practice that is hard to do well without one piece. For example, without test-driven development in XP, continuous integration is difficult to achieve. Scrum, however, is more about management and process practices. We can selectively use some of the processes and practices in Scrum and add more practices as we go along. Of course, this is also the most difficult place, reading is easy, the road is difficult, interested students to act quickly!

Reference Documents:

Textbook of a Training Institution

User Stories and Agile Methods

“Effectively Pass the PMI-ACP Exam (2nd Edition)”

Agile Project Management and PMI-ACP Test Taking Guide