Microsoft has recently released Visual Studio Scrum 1.0 Process Template, this template has been designed to support the Scrum Teams working with TFS.
Scrum is an iterative, incremental framework for project management and agile software development. This template includes work items and reports to help Scrum teams to be successful.
First let me give an overview on Scrum Roles & Scrum Contents, so that it will be easy to understand the Scrum Process Template.
o Scrum Master: He is the one who will be responsible for ensuring the process is understood and followed.
o Scrum Team: which does the work. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.
o Sprint Retrospective: It is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.
o Product Owner: who is responsible for maximizing the value of the work that the Scrum Team.
o Sprint: A Sprint is an iteration. Sprints are time-boxed. During the Sprint, the ScrumMaster ensures that no changes are made that would affect the Sprint Goal. Both Team composition and quality goals remain constant throughout the Sprint. Sprints contain and consist of the Sprint Planning meeting, the development work, the Sprint Review, and the Sprint Retrospective. Sprints occur one after another, with no time in between Sprints.
Visual Studio Scrum 1.0 Process Template includes:
Work Item Types
- Sprint : By defining and managing sprint work items, team can capture the goal, the start and end dates, and the retrospective results for each sprint in a project. During a sprint planning meeting, team determines the sprint goal and the number of product backlog items that team members can accomplish over the upcoming sprint. Scrum Master makes sure that the sprint goal remains constant throughout the sprint. At the end of each sprint, team discusses what went well and what did not go well during the sprint and then decides what team members can do differently to make the next sprint more effective.
- Product Backlog Item : The requirements for the product that the Team is developing are listed in the Product Backlog. By defining and managing product backlog items, teams capture the requirements of the product. The Product Owner is responsible for the Product Backlog, he is the one who defines defines, prioritizes, and maintains backlog items. The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases. The team estimates the effort, the business value and the priority for each backlog item and delivers the highest priority items in each sprint.
- Bug: By defining and managing bug work items, team can track defects in the product and prioritize efforts to resolve them. When you define a bug, you should perform the following tasks
- Task : By defining and managing task work items, team can track and report on the detailed work that it must accomplish for a product backlog. Teams typically forecast work and define tasks at the start of each sprint, and each team member performs a subset of those tasks. Tasks can include development, testing, and other kinds of work. For example, a developer can define tasks to implement product backlog items, and a tester can define tasks to write and run test cases.
- Impediment : By defining and managing impediment work items, team can identify and track problems that prevent it from completing tasks efficiently. Teams typically identify impediments during daily scrums. The scrum master is responsible for helping resolve these impediments and improve team productivity.
- Test Case: A team uses test cases to define both manual and automated tests that can be run and managed by using Microsoft Test Manager. By using Microsoft Test Manager, you can create not only test cases but also test suites and test configurations that support testing your project. You can use test configurations to define how you want to run your test cases and test suites. You can group your test cases together by organizing them into a hierarchy of test suites in your test plan. By creating test suites, you can run sets of test cases as a group.
- Shared Steps: Your team can use shared steps to streamline definition and maintenance of manual test cases. Many tests require the same sequence of steps to be performed for multiple test cases. By creating shared steps, you can define a sequence of steps once and insert it into many test cases. For example, if each test case requires a tester to log on to the application, you can create a set of shared steps to perform these actions. You can then add the shared steps to each test case and run the steps using Test Runner.
Reports:
o Release Burndown: By reviewing a release burndown report, you can understand how quickly your team has delivered backlog items and track how much work the team must still perform to complete a product release.
o Velocity: If your team has completed multiple sprints, you can forecast release and product completion dates and plan future projects more accurately by reviewing the velocity report.
o Sprint Burndown: By reviewing a sprint burndown report, you can track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.
o Build Success Over Time: The Build Success Over Time report provides a pictorial version of the Build Summary report. The Build Success Over Time report displays the status of the last build for each build category run for each day. You can use this report to help track the quality of the code that the team is checking in. In addition, for any day on which a build ran, you can view the Build Summary for that day.
o Build Summary: The Build Summary lists builds and provides information about test results, test coverage, code churn, and quality notes for each build.
o Test Case Readiness: After the team starts to define test cases, you can use the Test Case Readiness report to determine how many test cases have been defined and are ready to run.
o Test Plan Progress: After the team creates test plans and starts to run tests by using Microsoft Test Manager, you can use the Test Plan Progress report to track the team's progress in testing the product.