The Visual Studio Team architect Agile Software Development (PART II)

To continue the whole line of thinking, I will also involve some of the ways in which our team plans to sprint and what happens during the sprint, interspersed with answers to the questions you ask.

First of all, I want to say that there is no such thing as agile without a plan. However, the plan in agile development is really different from the traditional software development plan. As I said in my last blog post, we created a prioritized product for development (product backlog) for the top level requirements given by stakeholders (stakeholders). This prioritized task list forms the most basic sprint plan. In this process, we typically follow the three-stage step: The planned phase of the executive, the planning stages that all team members participate in, and the plan submission phase that includes stakeholders. The key here is that the plan is in the full cooperation of all the members, and most importantly, it is up to the team to set standards spontaneously, rather than relying on a project manager.

The projected phase is in the last week of the previous sprint, during which the team leads the project manager, and several development and testing executives gather together to discuss a list of stories to be developed in the upcoming next sprint. Story The process depends on a number of factors, the most important of which is the progress of the previous sprint, the feedback from stakeholders, the change in requirements or story priorities, and the expected team speed. The project manager, sometimes even a developer or tester, tries to brief the story as short as possible to describe only the goal, the brief description of the story, and the specific process of the story. We found that OneNote was a good fit for our needs (a screenshot of a story will be given later).

Products to be developed always list items that are valuable to the customer, and it can also increase the items required by the team. However, only those items that will eventually bring value to the customer can appear in the pending development issues. For example, to create and maintain a continuous integration server to continuously guarantee the quality of the final product, such entries are allowed to appear in the pending development issues.

The planning phase usually is on the first day of the sprint. Before the meeting, the project manager sends a link to the OneNote page to the team members for evaluation and preparation for the scheduled meeting. Usually, the team members will exchange views on the OneNote page to clarify the unclear areas before the meeting. On the day of the planning meeting, team members gather together, take a look at all the stories, solve any problems that have been identified, further divide the story into tasks, and describe the acceptance tests for each story. The team also makes a rough estimate of the time it takes to complete these stories, and then based on these estimates, decide what stories the teams can accomplish in the sprint.

The planning submission phase will take place the following day, with the supervisor gathering again and briefing stakeholders on the tasks that the team is committed to accomplishing. At this point, stakeholders can make recommendations to adjust the priority level. For example, if a team member can complete the story a,b and C, but cannot complete D and E, stakeholders can advise the team to complete the a,b,d and E (assuming the total time consumed by D and E is the same as C) in this sprint. The project manager then enters these stories into the visual Studio team Foundation Server that is used to manage our project.

Note: We have spent several sprints to learn and summarize the above planning process. This is the important role that sprint reviews (which I will mention in future posts) play.