October 4, 2010 at 05:21Scrum Process Template for Team Foundation Server
Among the many development teams, the Scrum approach is gaining in popularity. Indeed, a concise methodology of 20 pages of text is easy to understand and, after some practice, begins to be used. That's why Microsoft has released an optional Scrum template that allows you to use this methodology with Team Foundation Server.
Those who already use TFS in their work know that to organize the work of the team, two process templates can be used - MSF Agile and MSF CMMI. Technologically, these templates are a set of files that describe process work items, documents, reports, security settings, and so on. Moreover, TFS allows you to customize these templates , supplementing them with some properties that are specific to this command. Such modifications are conveniently done using Visual Studio Power Tools . The market has several additional process templates developed by the community and commercial companies.
This template was developed by Microsoft experts with the direct participation of experts from Scrum.Org. Like the standard MSF Agile and MSF CMMI, it primarily consists of a set of work items that are designed to organize the work of the team:
Productuct Backlog Item (PBI): Tracking requirements for the entire software product.
Bug: Found a bug during development. It should be noted that Product Backlog Item and Bug are almost equivalent elements of the requirements list in the context of cost estimates and planning. Hence the almost identical set of fields. A small remark. Unlike MSF Agile and MSF CMMI Templates, TFS does not create a Bug based on an erroneous build.
Task:Task. This item allows you to enter the required level of detail for the Product Backlog Item. Naturally, the tasks themselves can be divided into subtasks.
Sprint: This work item captures sprint dates, goals, and retrospectives. Separating a Sprint into a separate work item distinguishes the Scrum template from the MSF Agile and MSF CMMI templates. In them, the sprint is indicated only by the mechanism of iteration hierarchies, but unfortunately it is not possible to indicate the start and end dates of the sprint using it.
Impediment: Problems, risks and all that can affect the work of the team but is not directly related to the properties of the developed product.
Test Case:Test description for PBI. Typically, tests are directly tied to a specific PBI. This work item (as in the other Shared Steps) is not defined directly in Scrum but it is necessary for the TFS infrastructure to work correctly.
Shared Steps: Shared test steps between multiple Test Case.
Actually, the work process itself is well described in the Scrum manual and a very brief example of the steps is given below:
1) A project team is formed and the minimum necessary documents are prepared (Vision, Scope)
2) An initial PBI list is generated and where possible priorities are assigned. This stage of analytics, as a rule, is not long.
3) Based on the initial PBI list, the first evaluation (Effort Field) is carried out using Planning Poker. Do not forget that these are abstract units, although you can plan in hours.
a. Those PBIs that are not clear (evaluation of the level of infinity or very high costs) are sent to additional analytics.
4) The first sprint is formed based on the priorities and significance of the PBI from the full set of Product Backlog, and which it is already clear how to implement.
5) PBI that got into Sprint are detailed by developers to the task level (Task) where necessary. Here you can enter the time. Task has a Remaining Work field.
a. After two or three Sprint, you can already expect uniqueness in costs and clarify the planning horizon.
6) The PBI is checked in the Commited state based on the specified Test Case.
7) Inevitably occurring errors should be fixed using Bug, which also fall into the Product Backlog.
8) Completed PBIs are closed with the status of Done
9) The next Sprint is planned, the process is repeated from p.p. 5.
Manipulations with the PBI / Bugs / Task lists within the Product Backlog and Sprint are carried out using standard queries that are already defined in the template for Sprint 1.
Accordingly, after the first sprint has ended, remember to change the Sprint Backlog query to the current sprint value:
Work item states Scrum
The MSF Agile and MSF CMMI templates use the already established TFS ARC approach (Active-> Resolved-> Closed) which does not quite correspond to Scrum terms.
Let me remind you that you can familiarize yourself with the Workflow of all work items in more detail both on the MSDN website , and with the help of Team Foundation Server Web Acces and Process Editor.
For example, I’ll give a screenshot from the Wokflow editor for the Bug work item (which is the most complex) of the Scrum process: Scrum
reports
Naturally, almost all the fields that are defined in Scrum work items fall into Team Foundation Server analytics systems and allow you to build several important reports that later provide an opportunity to understand how things are going on the project.
Sprint / Release Burndown - two reports that provide an opportunity to assess the amount of remaining work on the project and sprint.
Release Burndown: From sprint to sprint, the total volume of tasks estimated in Effort units should decrease. Indirectly through this graph, you can also evaluate team performance.
Sprint Burndown: Every day, the team closes a number of PBIs as part of the sprint.
Velocity Report: Efforts spent on each sprint. This report resonates with Release Burndown. The graph also shows the average figure (35) of the team's performance in the sprint. Ideally (and to an invariable team), the more sprints there were, the more accurate this figure was, and the more accurately one could predict the end date of the project.
Build Success Over Time, Build Summary reports: show the status of project assemblies by platform and tests passed. Allows you to understand progress, the extent of change and evaluate the quality of the product.
Test reports are designed to assess the general state of product quality, as well as solve organizational issues related to the tests themselves. Based on the information presented in these reports, you can understand how many tests from date to date pass with the correct result, how many with the wrong result, how many have not yet been launched, and how many tests are blocked.
The Test Case Readiness report allows you to organize work with tests, showing how many tests are ready for execution and how many are still at the stage of detailing. Ideally, this report should draw a picture like this:
The Scrum process template is one of the simplest process templates for Team Foundation Server, which nonetheless allows you to solve the basic issues of organizing teamwork. Moreover, the brevity of Scrum allows you to quickly introduce this approach into new or existing teams and get a visible result in a fairly short period of time. Which, I want to believe, will consist in the development of better software and accurate planning.
Process templates
Those who already use TFS in their work know that to organize the work of the team, two process templates can be used - MSF Agile and MSF CMMI. Technologically, these templates are a set of files that describe process work items, documents, reports, security settings, and so on. Moreover, TFS allows you to customize these templates , supplementing them with some properties that are specific to this command. Such modifications are conveniently done using Visual Studio Power Tools . The market has several additional process templates developed by the community and commercial companies.
Scrum Process Template
This template was developed by Microsoft experts with the direct participation of experts from Scrum.Org. Like the standard MSF Agile and MSF CMMI, it primarily consists of a set of work items that are designed to organize the work of the team:
Productuct Backlog Item (PBI): Tracking requirements for the entire software product.
Bug: Found a bug during development. It should be noted that Product Backlog Item and Bug are almost equivalent elements of the requirements list in the context of cost estimates and planning. Hence the almost identical set of fields. A small remark. Unlike MSF Agile and MSF CMMI Templates, TFS does not create a Bug based on an erroneous build.
Task:Task. This item allows you to enter the required level of detail for the Product Backlog Item. Naturally, the tasks themselves can be divided into subtasks.
Sprint: This work item captures sprint dates, goals, and retrospectives. Separating a Sprint into a separate work item distinguishes the Scrum template from the MSF Agile and MSF CMMI templates. In them, the sprint is indicated only by the mechanism of iteration hierarchies, but unfortunately it is not possible to indicate the start and end dates of the sprint using it.
Impediment: Problems, risks and all that can affect the work of the team but is not directly related to the properties of the developed product.
Test Case:Test description for PBI. Typically, tests are directly tied to a specific PBI. This work item (as in the other Shared Steps) is not defined directly in Scrum but it is necessary for the TFS infrastructure to work correctly.
Shared Steps: Shared test steps between multiple Test Case.
Work organization
Actually, the work process itself is well described in the Scrum manual and a very brief example of the steps is given below:
1) A project team is formed and the minimum necessary documents are prepared (Vision, Scope)
2) An initial PBI list is generated and where possible priorities are assigned. This stage of analytics, as a rule, is not long.
3) Based on the initial PBI list, the first evaluation (Effort Field) is carried out using Planning Poker. Do not forget that these are abstract units, although you can plan in hours.
a. Those PBIs that are not clear (evaluation of the level of infinity or very high costs) are sent to additional analytics.
4) The first sprint is formed based on the priorities and significance of the PBI from the full set of Product Backlog, and which it is already clear how to implement.
5) PBI that got into Sprint are detailed by developers to the task level (Task) where necessary. Here you can enter the time. Task has a Remaining Work field.
a. After two or three Sprint, you can already expect uniqueness in costs and clarify the planning horizon.
6) The PBI is checked in the Commited state based on the specified Test Case.
7) Inevitably occurring errors should be fixed using Bug, which also fall into the Product Backlog.
8) Completed PBIs are closed with the status of Done
9) The next Sprint is planned, the process is repeated from p.p. 5.
Manipulations with the PBI / Bugs / Task lists within the Product Backlog and Sprint are carried out using standard queries that are already defined in the template for Sprint 1.
Accordingly, after the first sprint has ended, remember to change the Sprint Backlog query to the current sprint value:
Work item states Scrum
The MSF Agile and MSF CMMI templates use the already established TFS ARC approach (Active-> Resolved-> Closed) which does not quite correspond to Scrum terms.
- This template uses other state names:
- PBI, Bug: New-> Approved-> Commited-> Done
- Task: To Do-> In Progress-> Done
- Impediment: Open-> Closed
Let me remind you that you can familiarize yourself with the Workflow of all work items in more detail both on the MSDN website , and with the help of Team Foundation Server Web Acces and Process Editor.
For example, I’ll give a screenshot from the Wokflow editor for the Bug work item (which is the most complex) of the Scrum process: Scrum
reports
Naturally, almost all the fields that are defined in Scrum work items fall into Team Foundation Server analytics systems and allow you to build several important reports that later provide an opportunity to understand how things are going on the project.
Sprint / Release Burndown - two reports that provide an opportunity to assess the amount of remaining work on the project and sprint.
Release Burndown: From sprint to sprint, the total volume of tasks estimated in Effort units should decrease. Indirectly through this graph, you can also evaluate team performance.
Sprint Burndown: Every day, the team closes a number of PBIs as part of the sprint.
Velocity Report: Efforts spent on each sprint. This report resonates with Release Burndown. The graph also shows the average figure (35) of the team's performance in the sprint. Ideally (and to an invariable team), the more sprints there were, the more accurate this figure was, and the more accurately one could predict the end date of the project.
Build Success Over Time, Build Summary reports: show the status of project assemblies by platform and tests passed. Allows you to understand progress, the extent of change and evaluate the quality of the product.
Test reports are designed to assess the general state of product quality, as well as solve organizational issues related to the tests themselves. Based on the information presented in these reports, you can understand how many tests from date to date pass with the correct result, how many with the wrong result, how many have not yet been launched, and how many tests are blocked.
The Test Case Readiness report allows you to organize work with tests, showing how many tests are ready for execution and how many are still at the stage of detailing. Ideally, this report should draw a picture like this:
Conclusion
The Scrum process template is one of the simplest process templates for Team Foundation Server, which nonetheless allows you to solve the basic issues of organizing teamwork. Moreover, the brevity of Scrum allows you to quickly introduce this approach into new or existing teams and get a visible result in a fairly short period of time. Which, I want to believe, will consist in the development of better software and accurate planning.