Start with 5 Meetings to Talk About Scrum Agile Development Practices

I. Development Mode

Our team uses the Scrum Agile Development Model. The advantage of this model is that it is more flexible than the traditional waterfall development but has higher requirements for everyone on the team. There are three roles in Scrum: PO, Scrum Master, and Project Members. I am the role of Product Owner of the team.

Generally, product managers may start prototyping and writing PRD documents after requirements analysis and determination of requirements. But in this development mode, I do not write PRD documents. I will put all the ideas on the prototype and add notes to it, so if developers encounter problems, they will find me to ask for clear requirements. This is because the most critical point of Scrum is to communicate more and replace documents with communication.

Of course, if you give the prototype directly to the developer during development, they will feel confused and want to beat you up. For the personal safety of the product manager, I have to talk about the five Scrum meetings: a requirements clarification meeting, a plan analysis meeting, a stand-up meeting, a review meeting, and a retrospective meeting.

1. Requirements Clarification Meeting

Requirements clarification meeting, as the name implies, is to clarify requirements, but others will have doubts. What requirements do you clarify without PRD? Yes, what I prepare is User Story: if I am a user of this product, what function do I want to implement? The function described here may be "I want to have the function of adding, deleting, changing, and checking XXX" instead of detailing "where to put my submit button." Simply put, this user story has a certain granularity, but it is unambiguous under the understanding of all product designers, developers, and users. There is no problem as long as we are sure we need to do such a thing.

Because there are many user stories, we usually prioritize the user story and then divide them into several sprints according to the priority, which is continuous iteration. Each iteration cycle is very short, usually one or two weeks. The iterated product may have some defects, but it must be a product that can be used normally.

2. Plan Analysis Meeting

The plan analysis meeting divides tasks according to the prototype and user stories. Scrum Master usually hosts this meeting. Of course, the Scrum Master here is not the one you think. Because we have held a requirements clarification meeting before, and the developers know what kind of product needs to be developed, at this time, we can divide the tasks into prototypes according to each user story. What we need to pay attention to is that each task here is assigned to them by the developers. For example: How many interfaces do the back-end developers need to write when they see this page? How many hours does each interface take? How do the front-end personnel need to cooperate? These are all things that need to be figured out in this meeting. Therefore, this meeting will generally be relatively long, about 4-5 hours for the follow-up normal development.

3. Stand-Up Meeting

This is a meeting that needs to be held every day. Each project member talks about what they did yesterday and what they plan to do today. This conference is mainly about the cooperation between front-end developers and back-end developers to avoid the embarrassing situation that the front-end has already made an interface but has no interface docking.

4. Review Meeting

The review meeting is mainly to conduct the functional review of this iteration. According to the user stories, we can see whether we have completed the content of these user stories.

5. Retrospective Meeting

This meeting analyzes the strengths and weaknesses of our team in this iteration, how we can improve it, and proposes corresponding improvement measures.

Agile Manifesto: Individuals and interactions are superior to processes and tools; Working software is superior to detailed documents; Customer cooperation is superior to contract negotiation; Responding to changes is superior to following the plan.

II. Problems Encountered in the First Iteration and Improvement Plan

1. Task omission

When we first used this pattern to develop, the biggest problem we encountered was task omission. This shows that we did not divide the tasks properly during the planning meeting, and the lack of communication may be the main reason for this problem. The solution to the problem is that our front-end and back-end staff need to consider the priority of tasks when receiving tasks, decide which to do first and which to do later, and communicate more. If the workload of a task is more than 8 hours, we recommend subdividing the task further and trying to make the workload of each task within one day. This way, dividing the task into more detailed tasks can also avoid missing ones. If we find a task missed during development, the solution can only be to work overtime.

2. Interface documents are not updated in time

This is the fault of back-end developers. Of course, the solution is promptly updating and signing the interface document.

3. User story omissions and insufficient details in the prototype

Of course, the PO is also responsible for the iteration going wrong. In the absence of detailed PRD documentation, prototypes become the main reference for developers. The developer cannot develop if missing items in the user story and the prototype are not drawn. Even if we use an agile development model and communication is at the core, this significantly increases communication costs. Therefore, the control of user stories, understanding of prototyping, and thinking about business processes should be the biggest challenge for product managers new to the agile model.

4. The Test is not Standard

Without testers, product managers are the best testers in the project. In fact, this is not the most accurate statement. The product manager should control the last step of testing, rather than the developer giving a module to the product manager for testing when the developer has developed the module and has not self-tested it. This not only increases the workload of the product manager but also may lead to project delays. Therefore, the agile model tests everyone's ability in the whole team.

5. Resources not Identified Before Sprint

Just like our small start-up team, we have neither tests nor UI. If we need a UI, we must apply for outside resources. And if we don't consider that before iterating, our pages could come out badly.

III. Summary

As a new product manager, my understanding of agile still deepens in my continuous work. From the theoretical content I learned in Mike Cohn's book " User Stories Applied: For Agile Software Development" at the beginning to a little practice in actual development, my agile thinking is slowly growing.