User stories and Agile methods read Note 03

10th Iteration Plan

Drawing up the results release plan for the previous chapter, we can successfully assign the story of thickness to the Duolun iteration. Duolun iterations are a further intensification of the release plan, but only when the iteration is about to begin does the iteration plan begin. To do this, an iterative planning meeting is essential, and the customer and all the people on the team are involved. In this process, each person carefully discusses each story, breaks down the task from the story, and the developer takes responsibility for each task. This meeting is the best time for the customer to adjust the story for the team, but keep in mind that the project team is not at liberty to disrupt the development plan.

The size of the task does not have a mandatory range (for example: 3 hours to 5 hours). Instead, break down tasks from the story to help estimate or encourage multiple developers to work on a story. and to ensure that each task has a developer to bear, do not miss or lose any task. After each developer receives the task, the task volume should be measured to assess whether or not the commitment is excessive and, if so, the team should reassign the task to an average.

11th. Measuring and monitoring rate

We divide the project into a series of iterations to make a development plan, so that when each iteration completes the story task point, the current development rate can be identified to determine the next task and speed, and the schedule can be rescheduled.

The rate should be calculated by considering only those stories that have been completed, that is, through the acceptance test. Do not calculate the stories that the team has not completed in the iteration. For each iteration plan and the actually completed story point drawing, it is more effective and intuitive to detect the difference between the actual rate and the planned rate. The rate trend should be predicted after the Duolun iteration, and the result of premature prediction is often inaccurate. It's important to accumulate story points and burndown charts, which let us understand the story points that are completed in each iteration, while Burndown charts are used to show overall progress and remaining stories, and he also shows the remaining time of day. These diagrams should be placed in public areas so that the entire project team understands the development situation.

The 12th chapter is not what the story

The story is the center of the book's focus, and the core of the entire development project, and understanding the user story is therefore an essential thing. To make it easier to understand the user story, we can first understand what it is not.

This chapter explains the three requirements methods, which are: IEEE 830 (the Institute of Electrical and Electronics Engineers revised the "How to write a Software Requirements Specification Guide" in 1998), use cases, and interactive story scenarios. They have advantages and disadvantages, first of all, the IEEE document format is tedious, time-consuming and often impractical, and different users may understand different results; second, use cases are a general description of the interactions between systems and between one or more users. It is relative to the story, coverage is slightly larger, incomplete, easy to cause the story is not clear, and life is a factor of influence, use case is a permanent "artifact". Finally, the scenario is a detailed description of the user's interaction with the calculation. It is larger and more comprehensive than the use case scenario, and the difference between the story is the scope and the details.

It is also important to note the following: No matter how comprehensive the initial assumptions are, we cannot fully define a complete system with considerable scale, considering that the characteristics of the user's target scale-out scheme are of paramount importance.

User stories and Agile methods read Note 03