The previous article has given an introduction to scrum, and also explained the three roles stipulated by scrum. In this article, we will briefly talk about what the core process of scrum is.
Iteration planning meeting (sprint planning meeting)
In fact, scrum itself is a very concise framework. We introduced the product owner in the previous article. PO will organize a demand list called the product backlog. Then our topic today will start with this Backlog.
The product to-do list is a sorted list that contains all the things the product needs and is the only source of product demand changes. The product owner is responsible for the content, availability, and priority of the product to-do list.
From this description, we can know that the product to-do list is the carrier of requirements, but it is somewhat different from the traditional requirements specification. The traditional requirements document gives the impression that it is more of a large paragraph of text, and strive to pass Try to describe in detail as much as possible, explain the requirements clearly, thoroughly, and complete, and require the follow-up process to strictly abide by the requirements in the document, and implement step by step. And when we find that there is a difference between the actual requirements and the document description, we should approve through the formal change process. Only the changes approved by the key stakeholders can be reflected in the revised document, and the product to-do list in the scrum is stored It is a user story, which means that the description is more concise. Many details need to be further clarified in the follow-up communication, but conciseness does not mean randomness. User stories have their inherent writing format, and each user story should be able to correspond to the specific In terms of customer value, this product to-do list should also meet the following DEEP principles:
The appropriate thickness ( D etailed appropriately): the top ten percent do list might contain very small and very detailed analysis of the matter, while the other ninety percent are not so concrete;
estimate had ( E stimated ): product Owner team to-do list for each product matters effort estimation and technical risk estimates;
the emergence of formula ( E Mergent): to-do list regular grooming products. The product owner will constantly update the product to-do list to reflect changes in customer needs, new ideas or insights, changes caused by competition, technical obstacles, etc.;
prioritized ( P rioritized): The items at the top of the to-do list have the highest priority, or are arranged in order starting from 1.
Back to the scrum process we talked about. At the beginning of each sprint, we have a meeting called an iteration planning meeting. The important input of this meeting is the product to-do list we just mentioned. This meeting can be divided into two parts. Look, the first part is about "what to do", that is, you need to select from the product to-do list which user stories need to be completed in the current iteration, and this choice is made by the team, and of course which stories are selected must also When the product owner communicates and negotiates, when everyone can agree on what to do, the second half of the meeting can start, that is, the second part is about "how to do", the team needs to split the selected user story into specific Tasks, and this process of splitting often brings new gains, such as discovering new risks during splitting or encountering places that you don’t understand. So this process is also a good time to deepen the understanding of requirements. Simply organize the planning meeting. Summarized into the following steps:
1. Tell a story
2. Answer questions
3. Reorganize and estimate user stories
4. Choose to iterate user stories
5. Split into tasks
6. Check the rationality of the sprint backlog
7. Give promises
This step is not the so-called official standard. I just hope that friends who don’t know how to conduct the planning meeting can be used as a reference. The output of the planning meeting is another very important artifact in scrum: the sprint backlog, which is related to the product to-do list. There are many similar characteristics, but the content is tasks (although in actual work many companies are not divided into tasks), and each task in the list should have and only one person in charge.
Daily standup
After the planning meeting is over, the 1-4 week iteration begins. The specific iteration cycle is determined by each team according to their actual situation, but there are some rules that must be followed. After the iteration cycle is determined, do not change at will , If it is a week, each iteration is one week, if it is two weeks, each iteration should be two weeks. You cannot do it as long as you want. The time box must be observed.
In each day of the iteration, a daily scrum meeting (Daily Scrum Meeting) needs to be held. As the name implies, the daily scrum meeting is a meeting that needs to be held standing up. The reason for standing up is to hope that the meeting will not be too long (recommended not to exceed 15 minutes ), everyone is uncomfortable standing, just exchange the key information and end it quickly. If there are issues that need to be discussed in depth, you can communicate in other names after the meeting, because some content is not everyone at the stand. All need to pay attention. It is not necessary to let irrelevant people act as audiences. The communication issues of each member at the meeting are mainly three aspects:
1. What did I do yesterday;
2. What I plan to do today;
3. Are there any problems that hinder me;
在实际工作中，我发现有的组织对站会有误解，觉得每日站会就是每日晨会，必须在早晨刚上班的时候开，其实scrum并没有约束会议的具体时间，你可以选择早晨开也可以选择中午开，甚至是晚上下班再开，决定来源于团队，并且即使你选择了在早晨开，笔者也不赞成在早晨刚上班的时候开始，比如：如果每天9点上班，你把站会安排在9:10，那基本上很多人都会等待着9:10分开站会，大家会把站会当做一天工作的开始，这10分钟就这样被浪费掉了，你可以选择10:00开，或许效果会更好。但是不管怎么安排，时间和地点应该是固定的，这样让大家形成习惯和仪式感，在开站会的地点，我们一般会配置白板，通过结合看板对工作进行可视化促进站会的高效展开。
迭代评审会（Sprint Review Meeting）
迭代结束的时候，需要通过评审会议，来展示迭代的成果，出席会议的人有产品负责人、团队成员以及ScrumMaster，再加上客户、利益相关人、专家、领导层和任何有兴趣的人。评审会内容的展示对两个角色是非常重要的，第一个就是PO，作为产品负责人需要评判团队交付的功能是不是TA想要的，是否满足要求，所以PO也就是有一票否决权的人，而另外一个目的是展示给团队自己，有的朋友可能会有疑问，功能是团队交付的，为什么还要展示给自己看，其实不管你对这些功能有多么熟悉，在这样一个正式的场合进行展示时，这种成就感是非常重要的，也是团队非常需要的， 就像马斯洛需求层次理论里表述的一样，每个人的需求层次不一样，我们满足的方式也要有所区别，而评审会就是要满足高层级的被尊重需求和自我实现的需求，所以评审会议不仅是交付功能给相关方的动作，也是团队自己付出努力的一个总结。
关于评审会还有一个很重要的观念，评审会不是评比会，评比会是要比较谁做的好，谁做的不好，而评审会要从团队整体的交付出发，不会有针对个人的排名，个人的比较对团队的帮助比你预想的要小的多。
迭代回顾会议（Sprint Retrospective Meeting）
迭代回顾会议是个人认为在敏捷中最重要的会议，但是在实际工作中很多团队都没有开好，甚至就没有开这个会议，敏捷强调的是适应性，是根据面临的变化不断调整的，如果团队不回顾，又如何有新的想法和思路，又如何优化现有流程和机制？
会议可以从如下的五个方面考量：
1、哪些方面产生的价值较少要尽量少做；
2、哪些方面效果很好可以多做；
3、哪些工作需要保持现状；
4、哪些方面可以考虑做一些新的尝试；
5、哪些方面要坚决杜绝，不要再发生。
至于会议的议程，也可以参考如下的步骤：
1、预设会议基调；
2、收集数据；
3、激发灵感；
4、决定做什么；
5、总结收尾。
- 预设会议基调 是要陈述会议议程和会议规则，这个过程并不是一直要做的，如果团队已经非常成熟，对回顾会议也驾轻就熟，那就没有必要每次都陈述会议议程了；
- 收集数据 是为了后续的决策做准备，而数据的收集也可以通过一些工具和方法来获得，比如时间线法、雷达图法等；
- 激发灵感 可以考虑组织头脑风暴并结合一些分析工具来进行，这个过程非常重要的一点就是全员参与、集思广益；
- 决定做什么 比较强调确定下来的任务应该是具备可操作性，比如是否符合smart原则的，任务应该有明确的时间要求、可实现、可验证才能确保有效落地，如果回顾会上确定的改进项都不能落地那还不如没有改进项，杜绝浪费也是团队要时刻关注的点，而scrum master也要起到监督、发现并引导团队做有价值工作的作用。
- Summary ending in addition to the summary should also be carried out thanks to activities within the team for this iteration helped you, thank you pay, if you embarrassed expression, you can use Kanban wall to write out the words to say on the wall , This is also an effective measure to build a team atmosphere.
Regarding the meeting rules in practice, many teams are more likely to make a mistake, that is, there is no restriction on the participants, and they don’t express what they don’t want to express. Many colleagues in IT are unwilling to express. If you open this hole, Don’t say what you don’t want to say. Gradually you will find that the retrospective is silent, Everyone has nothing to say, this is also in line with the broken window theory.
Take a building with a few broken windows as an example. If those windows are not repaired, vandals may damage more windows. Eventually they will even break into the building, and if they find no one is inhabited, they may settle there or set fire. If there are some graffiti on a wall that has not been cleaned, it will soon be covered with messy and unsightly things; a sidewalk will have a little confetti, and there will be more rubbish soon, and eventually people will look at it. As a matter of course, discard the garbage on the ground. This phenomenon is the broken window effect in criminal psychology .
The above is a brief description of the scrum process, mainly around four key meetings. In fact, there is another meeting that did not mention it, which is the product to-do list combing meeting. This will be the next one in the iterative process. For the iterative to-do list, we cannot hope to sort out the to-do list at the iterative planning meeting. The input of the planning meeting should be a to-do list that has been sorted out, so as to ensure the efficient development of the planning meeting. While paying attention to the development skills of each conference, there is actually a lot of content that can be discussed. We will make some targeted introductions in subsequent articles. You are also welcome to continue to follow the series of articles.
