Scrum Process Template for Team Foundation Server
Among many development teams, the Scrum approach is becoming increasingly popular. Indeed, a concise, 20-page methodology is easy to understand and, after some practice, begin to use. That is why Microsoft has released an additional Scrum template that allows you to use this methodology with Team Foundation Server.
Those who already use TFS in their work know that two process templates can be used to organize the team’s work - MSF Agile and MSF CMMI. Technologically, these templates are a set of files that describe the working elements of a process, documents, reports, security settings, and so on. Moreover, TFS allows you to customize these templates , complementing them with some properties that are specific to this command. Such modifications are conveniently done using Visual Studio Power Tools . There are several additional process templates on the market developed by 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 in the development process error. It should be noted that the Product Backlog Item and Bug are practically equivalent elements of the list of requirements in the context of cost estimates and planning. From here and almost identical set of fields. A small note. 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 split into subtasks.
Sprint: This work item records sprint dates, goals and retrospectives. Selecting 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 with the help of the iteration hierarchy mechanism, but unfortunately with the help of it it is not possible to mark the start and end dates of the sprint.
Impediment: Problems, risks and everything 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 Shared Steps and others) is not defined directly in Scrum, but it is necessary for the correct operation of the TFS infrastructure.
Shared Steps: Shared Steps between multiple Test Case.
Actually the process itself is well described in the Scrum manual and below is a very brief example of steps:
1) A project team is formed, and the minimum necessary documents are prepared (Vision, Scope)
2) A primary PBI list is formed and priorities are assigned where possible. This stage of analytics, as a rule, is not long.
3) Based on the PBI primary list, the first assessment is carried out (Effort Field) using Planning Poker. We should not forget that these are abstract units, although it is possible to plan in hours.
a. Those PBIs that are not understood (infinity level estimates 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 are already clear how to implement.
5) PBIs that hit 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, one can expect uniqueness in costs and clarify the planning horizon.
6) A PBI in Commited state is checked based on the specified Test Case.
7) The inevitable errors should be fixed with the help of Bug, which also fall into the Product Backlog.
8) Completed PBIs close with Done status
9) The next Sprint is planned, the process is repeated with p. five.
Manipulations with PBI / Bugs / Task lists within the Product Backlog and Sprint are performed using standard queries that are already defined in the template for Sprint 1.
Accordingly, after the end of the first sprint, you should remember to change the “Sprint Backlog” query to the current sprint value:
Scrum Work Item States
In the MSF Agile and MSF CMMI templates, the ARC (Active-> Resolved-> Closed) approach already established in TFS is used, which does not quite correspond to the Scrum terms.
Let me remind you that in more detail the Workflow of all work items can be found both on the MSDN website and through the Team Foundation Server Web Acces and Process Editor.
For example, here’s a screenshot from the Wokflow editor for the Bug work item (it’s most complex) of the Scrum process:
Scrum Reports
Naturally, almost all the fields that are defined in the work elements of Scrum, get into the systems of analysts Team Foundation Server and allow you to build several important reports that later make it possible to understand how things are going on the project.
Sprint / Release Burndown - two reports that provide an opportunity to assess the amount of work remaining on the project and the sprint.
Release Burndown: From sprint to sprint, the total amount of tasks estimated in Effort units should decrease. Indirectly, through this graph, you can also evaluate the performance of the team.
Sprint Burndown: Every day the team closes a number of PBIs in the sprint.
Velocity Report: The effort that was spent on each sprint. This report echoes the release burndown. The graph also shows the average figure (35) of the team's performance in the framework of the sprint. Ideally (and unchanging team), the more sprints were, the more accurate this figure was, and the more accurately you can predict the end date of the project.
Build Success Over Time, Build Summary reports: show the status of project builds by platform and passed tests. Allow to understand the progress, the scale of changes and assess the quality of the product.
Test reports are designed to assess the overall state of product quality, as well as solve organizational issues related to the tests themselves. Based on the information provided in these reports, it is possible to understand how many tests from date to date pass with the correct result, how many with erroneous, how many have not yet been run, and how many tests have been blocked.
The Test Case Readiness report allows you to organize work with tests. It shows how many tests are already ready for execution and how many are still at the detailed stage. Ideally, this report should draw such a picture:
The Scrum process template is one of the simplest process templates for Team Foundation Server, which nonetheless solves the basic issues of teamwork. Moreover, the brevity of Scrum allows you to quickly implement this approach in new or existing teams and get a visible result in a relatively short period of time. Which, I want to believe, will be the development of better software and accurate planning.
Process templates
Those who already use TFS in their work know that two process templates can be used to organize the team’s work - MSF Agile and MSF CMMI. Technologically, these templates are a set of files that describe the working elements of a process, documents, reports, security settings, and so on. Moreover, TFS allows you to customize these templates , complementing them with some properties that are specific to this command. Such modifications are conveniently done using Visual Studio Power Tools . There are several additional process templates on the market developed by 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 in the development process error. It should be noted that the Product Backlog Item and Bug are practically equivalent elements of the list of requirements in the context of cost estimates and planning. From here and almost identical set of fields. A small note. 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 split into subtasks.
Sprint: This work item records sprint dates, goals and retrospectives. Selecting 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 with the help of the iteration hierarchy mechanism, but unfortunately with the help of it it is not possible to mark the start and end dates of the sprint.
Impediment: Problems, risks and everything 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 Shared Steps and others) is not defined directly in Scrum, but it is necessary for the correct operation of the TFS infrastructure.
Shared Steps: Shared Steps between multiple Test Case.
Work organization
Actually the process itself is well described in the Scrum manual and below is a very brief example of steps:
1) A project team is formed, and the minimum necessary documents are prepared (Vision, Scope)
2) A primary PBI list is formed and priorities are assigned where possible. This stage of analytics, as a rule, is not long.
3) Based on the PBI primary list, the first assessment is carried out (Effort Field) using Planning Poker. We should not forget that these are abstract units, although it is possible to plan in hours.
a. Those PBIs that are not understood (infinity level estimates 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 are already clear how to implement.
5) PBIs that hit 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, one can expect uniqueness in costs and clarify the planning horizon.
6) A PBI in Commited state is checked based on the specified Test Case.
7) The inevitable errors should be fixed with the help of Bug, which also fall into the Product Backlog.
8) Completed PBIs close with Done status
9) The next Sprint is planned, the process is repeated with p. five.
Manipulations with PBI / Bugs / Task lists within the Product Backlog and Sprint are performed using standard queries that are already defined in the template for Sprint 1.
Accordingly, after the end of the first sprint, you should remember to change the “Sprint Backlog” query to the current sprint value:
Scrum Work Item States
In the MSF Agile and MSF CMMI templates, the ARC (Active-> Resolved-> Closed) approach already established in TFS is used, which does not quite correspond to the 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 in more detail the Workflow of all work items can be found both on the MSDN website and through the Team Foundation Server Web Acces and Process Editor.
For example, here’s a screenshot from the Wokflow editor for the Bug work item (it’s most complex) of the Scrum process:
Scrum Reports
Naturally, almost all the fields that are defined in the work elements of Scrum, get into the systems of analysts Team Foundation Server and allow you to build several important reports that later make it possible to understand how things are going on the project.
Sprint / Release Burndown - two reports that provide an opportunity to assess the amount of work remaining on the project and the sprint.
Release Burndown: From sprint to sprint, the total amount of tasks estimated in Effort units should decrease. Indirectly, through this graph, you can also evaluate the performance of the team.
Sprint Burndown: Every day the team closes a number of PBIs in the sprint.
Velocity Report: The effort that was spent on each sprint. This report echoes the release burndown. The graph also shows the average figure (35) of the team's performance in the framework of the sprint. Ideally (and unchanging team), the more sprints were, the more accurate this figure was, and the more accurately you can predict the end date of the project.
Build Success Over Time, Build Summary reports: show the status of project builds by platform and passed tests. Allow to understand the progress, the scale of changes and assess the quality of the product.
Test reports are designed to assess the overall state of product quality, as well as solve organizational issues related to the tests themselves. Based on the information provided in these reports, it is possible to understand how many tests from date to date pass with the correct result, how many with erroneous, how many have not yet been run, and how many tests have been blocked.
The Test Case Readiness report allows you to organize work with tests. It shows how many tests are already ready for execution and how many are still at the detailed stage. Ideally, this report should draw such a picture:
Conclusion
The Scrum process template is one of the simplest process templates for Team Foundation Server, which nonetheless solves the basic issues of teamwork. Moreover, the brevity of Scrum allows you to quickly implement this approach in new or existing teams and get a visible result in a relatively short period of time. Which, I want to believe, will be the development of better software and accurate planning.
Source: https://habr.com/ru/post/105462/
All Articles