Agile Development Experience 4

1.Sprint Review Meeting: Not for the development team to do a successful "speech"---meeting does not necessarily have powerpoints pictures and documents, usually the meeting will not take more than 30 minutes of preparation time, but simply display the results of the work, all participants can ask questions and suggestions.

2. After the Sprint review meeting, the development team will conduct a sprint review meeting. Some development teams skip this process, which is not appropriate because it is one of the important ways to make scrum successful. This is a great opportunity for the development team to discuss what methods can work and what doesn't, and to pass the improved approach consistently. The scrum development team, Product owner, and Scrum master soy milk attend the meeting, which is chaired by an external neutral; a good way to do this is to host each other's retrospective meetings by Scrum master, which can play a role in disseminating information across teams.

3. The agile Review is not a non-themed seminar, and everyone sits down and rushes a "strum" without any purpose, and this form does not help the project progress.

4.Scrum Review the process of the meeting:

1 "On the whiteboard written on the main principles of dominance;

2 "draw a long timeline with at least three pages of paper on the whiteboard.

3 "Write on the Whiteboard What our success stories are."

4 on the Whiteboard, write "What can be improved".

5 Write on the whiteboard who is responsible, then divided into two areas---team and company.

The highest guiding principles of the 5.Scrum Review Conference. "No matter what we return to, taking into account the known circumstances of the time, the skill and ability of the individual, the resources available, and the situation on hand, we understand and believe that everyone is committed to their work."

6. In the project process, the sooner the problem is dealt with, the less the cost and costs are to be paid. The problem is that when we're in the middle of a stressful development task, it's sometimes hard to spot these errors and become more aware of the serious consequences of these mistakes. By reviewing meetings, using team members to strike each other in good faith, or by repeatedly "exercising" the development process and methods, each member can be trained to "eyes".

7. When conducting a scrum review, it is only the first step to find the problem, and we also have a reasonable analysis of the causes of these problems, their classification, and therefore the responsibility to delineate the issues. We want to make clear whether these issues are internal to the team or are due to external factors, specifying handlers and processing time.

8. At the beginning of each sprint, we have to be clear about what needs to be demonstrated at the end of the sprint. Most of the time, if a scrum is not going very well, we often hear the reason for a sprint presentation, "For some reason, I have no way to show you this feature, but this feature is there, I just need to change a little bit of something to do." If so, these reasons will be overrun at a later stage. What we can do, in addition to rejecting these related User stories, should help the team understand what we need to see at the Sprint demo session at the beginning of each sprint. It is emphasized that we value the deliverable version, rather than a verbal one that is more capable of increasing.

Agile Development Experience 4