User stories and Agile methods read Note two

8th Chapter Estimating User Stories

Using story points we use "velocity" to represent the number of story points that a team completes (or expects to accomplish) in a round of iterations. Therefore, it is important to ensure that the metrics for each iteration of the story point are consistent. What if we use pair programming? The team uses no pair programming and has no impact on the story point estimates. The team can estimate the story point using ideal pair day or ideal personal days, and the difference will be expressed at the rate value. Some reminders that a story (perhaps an epic story) breaks down into a small story, the sum of these little story estimates does not need to be equal to the estimate of the beginning of that story or epic story. Similarly, a story breaks down into tasks. The sum of these task estimates does not need to be equal to the estimate of the story. Developer Responsibilities 1. Responsible for defining story points in one way and available and relevant to the team. Efforts to ensure consistency in this definition. 2. Be responsible for giving an honest estimate. Give a low estimate without succumbing to temptation or pressure. 3. Responsible for team estimation. 4. The responsible estimate should be consistent with other estimates. That is, all 2 points should be about the same story. Customer responsibility is responsible for participating in the estimation meeting, but your task is to answer the questions and clarify the details of the story. You don't have to participate in story estimation.

9th release Plan

When you plan to publish, it is necessary to know the approximate release date and the relative priority of the story that the customer expects. The story should be in a clear order (first, second, third, and so on) instead of using groupings such as "very high, high, medium" fuzzy order. The priority of the story is determined by the customer, but the idea of the developer is also taken into account. The usage rate converts an estimate of the ideal day to a calendar day. It is necessary to estimate the initial speed of the team. The developer responsibility is responsible for providing information (sometimes including basic assumptions and possible alternatives) to the customer to help her prioritize stories. Be responsible for making a trade-off between basic requirements or architectural requirements and other client requirements to avoid the unrealistic need to increase the priority of basic or architectural requirements. When the release plan is established, it is responsible for the project buffer based on the actual story point, including a certain length of time. The customer responsibility is responsible for prioritizing the user stories with an estimate of the value of the story. It is not enough to rank the stories as high, medium, and low for the three priority levels. Be responsible for expressing the release deadline honestly. Responsible for understanding the difference between the ideal day and the calendar day. When you want to prioritize different components of a story, the share splits the story. Be responsible for understanding why you should not condemn or criticize a programmer with a personal rate of 0.6, only because her rate is less than 1.0.

10th Iteration Plan

An iteration plan is a further plan for releasing a plan, but only when the iteration is about to begin does the iteration plan begin. The developer responsibility is responsible for participating in the iteration planning meeting. Be responsible for helping to divide all the stories into tasks, not just the stories you want to do. Responsible for the claimed tasks. Responsible for ensuring that the appropriate workload is undertaken. In the whole round of iterations, it is the responsibility to monitor the rest of the work, while also monitoring the remaining work of the teammates. If you can finish your work soon, it is a responsibility to help your teammates take part in the work. Customer responsibility is responsible for participating in the iteration planning meeting. is responsible for prioritizing the stories that are included in the iteration. Responsible for directing developers to deliver the maximum business value they can deliver. This means that, after the release plan is set, Rong has a higher-value story that is responsible for prioritizing to deliver maximum business value.

11th. Measuring and monitoring data

The actual number of hours spent completing a task or story has no effect on the rate of the secondary. The Daily Burndown chart is useful in iterations, and it shows the number of hours remaining per day in the iteration. Designing and testing a graph of the number of defects that occur on an average per story point can help us find out whether the increase in team rate is at the expense of quality. Developer responsibilities try to do the next story after completing a story. We prefer to see a small number of completed stories, not more unfinished stories. Managers or trackers in extreme programming projects should know how and when to draw these diagrams in this chapter. Customer responsibility knows the rate at which the team is aware of the difference between the actual rate and the planned rate and whether the plan needs to be adjusted. Add or delete stories for your publication to ensure that your team achieves the project goals as much as possible under various constraints.

User stories and Agile methods read Note two