This Tutorial explains how to do Agile Planning using Microsoft TFS which will help Project Managers Plan and Track Work across their Teams:
Among the various articles published in SoftwareTestingHelp.com on DevOps, we have seen some good articles on DevOps from the point of view of Continuous Integration and Continuous Delivery using Microsoft TFS, AWS and certainly open source tools like Ansible.
One of the pre-requisites for DevOps is a certain strong process like AGILE which brings in agility to the entire SDLC process wherein the focus area is to release software in a very timely manner with shorter release cycles and quick feedback. So to say the agile process focusses mainly on speed.
Table of Contents:
Agile Planning Using Microsoft TFS 2017
Before you go through different sections in this article, it would be good to get aware of some of the important terminologies used in Agile. These terminologies will be used throughout in this article.
Pre-Requisites: Microsoft TFS 2017
Create TFS Team Project Using SCRUM Process Template
We will first start by creating a TFS team project using the SCRUM template by following the steps mentioned below.
Login to Microsoft TFS 2017 and click on New Project.
Enter a project name and select Scrum as the template. Click on Create.
Once the project is created add members to the project by clicking on the + icon.
Create Product Backlog
As you are aware that Microsoft TFS is an integrated ALM tool that helps to create Work Items, do Project Planning, create Build Definitions and Release Definitions with the feature to perform manual testing.
Before any Agile planning, we need to start by defining Sprints which is a predefined timeframe for the work to be done. Click on Settings ->Work and then define the sprints with start and end dates.
Select the Sprint and set the start and end dates.
Here, we will be focusing on creating work items which will form an integral part of Agile planning. So let’s start by creating the product backlog which contains a prioritized list of all features to be the part of your application or product.
The product owner maintains this backlog and with the help of the scrum team, he decides the feasibility of working in a particular sprint.
To create a product backlog from the Work section menu select Backlogs.
Click on New, enter a Title for the backlog item and click on Add.
The Product Backlog Item is added to the backlog. In a theoretical sense, you can consider Product Backlog Item as a User Story or a Change Request. They will normally be decomposed in the multiple developer tasks and test cases.
You can also re-order based on priority. Just drag and drop the work items above or below.
Open the work item and add the effort. Here the effort can be as per the project needs of either story points or days or hours. The effort estimate would be added once the item is decomposed into tasks. Assign an owner in the ‘Assigned To’ section and set the ‘State’ to Approved for development. Click on Save and Close.
Next, assign the item to Sprint 1 by drag and drop to Sprint 1.
The Iteration path changes the item to Sprint1 as displayed in the below image.
As we move the item to Done State, the Velocity which defines the total number of story points which the scrum team achieves in a sprint is shown by clicking on the top right Velocity chart.
So, in summary, we can say that the team has completed 8 story points in Sprint 1 as shown in the velocity chart above.
Capacity Planning
For every Sprint, we can define the number of hours each member will be working for the project assigned to. The capacity view for each sprint defines this. This view also captures the activity each member works on like Design or Development or Reporting etc.
Click on the appropriate Sprint. In this case, open Sprint 1 and go to the Capacity view. Update as shown below.
In the above screenshot, since Dev1 user works only 4 hours a day during the sprint period of 2 weeks which is 10 working days. The Work Assigned To shows he is assigned to a Task that needs 8 hours to complete out of 40 hours for the sprint period of 2 weeks. This is calculated as 4 (hours per day) * 10 ( 2 weeks) = 40 hours.
A similar calculation is done for the Dev2 user.
Creating Tasks
As we now have the Product Backlog Item or User Story defined and also capacity planned for every user in the project, we can now break it up into developer tasks. On the work screen, click on the Sprint 1 and then click on Add Task sign + for the product backlog item.
Assign it to the developer and enter a value in hours for the remaining work field. Click on Save and Close.
Task created is linked to the Product Backlog Item.
Here, the Remaining work field is the number of hours left to complete a task. Since in the above example we have set the field to 8 hours and let’s say the developer at the end of a day has completed only 2 hours of work on the task, then the remaining hour’s field would be updated to 6. You could make it 0 when there is no more work, or if there is 1 hour or less work remaining or somewhere in between 0 and 1 hour.
From this value, TFS can create a burndown chart for the sprint which is one of the very useful metrics in Agile. The above process is for the SCRUM template and does not have the Original Estimate field in the Task work item.
If the TFS team project is configured using the Agile or CMMI process template then there is an option to enter the Original Estimate field.
To add the Original Estimate field (Microsoft.VSTS.Scheduling.OriginalEstimate) in the Task work item type using SCRUM process template it has to be added as a custom field. You can use the witadmin exportwitd, which is a command-line option. Add the field in the XML file exported and import it back into the team project.
Future Sprints
The Product Backlog Item or User Story can also be planned for the future by dragging and dropping the item to any other future sprint.
Using Taskboard
Since the Sprint Plan is in place, we can now view the progress of each Task from the Taskboard view. So the Taskboard provides a visual flow of the tasks and its status. So during every scrum meeting, you can look at the status of each task assigned to the members.
You can also view the summarization of the total remaining work to be completed.
It is very important to monitor the status and progress and can be done through the taskboard. Click on the Board view for the Sprint.
This board is a very useful view and can be used for reporting purposes during the daily standup meeting.
a) If the developers with assigned tasks have started working on the tasks then you can move the tasks from To do state to In Progress state by just drag and drop feature.
b) Change the remaining work hours of the task for a Dev2 user from 8 to 5 hours remaining. The In Progress task hours will then be updated accordingly.
c) The burndown chart, by clicking on the top right corner, is automatically updated.
d) Now close the task assigned to Dev2 by drag and drop the task to Done state. The remaining work hours for this task are automatically decreased to 0 and the burndown chart is also updated.
Sprint Review And Retrospective
Well, the work is done now and the sprint timeframe is over. Does the team think that it is now time to relax or take a break? Absolutely a big NO. The time is now to discuss the very important part of the SCRUM life cycle which is the review and retrospective.
Sprint review focuses on the deliverables, go through the DONE product backlog items, and provide a demo to the customers. Also, it is very important to discuss what product backlog items were not done and why and most importantly gather feedback from customers and plan them for future sprints. The sprint review is normally done between product owner, development team, and customers.
Sprint retrospective focuses on the aspects of the process like what went well and what did not? So you will also need to capture feedback about the process and people as well. As this is a very important aspect of the Agile lifecycle you can learn more on retrospectives.
So, it is very much possible that there could be unfinished work in every sprint. In this scenario move the PBI’s/Tasks to either Product Backlog or to the next Sprint which the Product Owner decides.
But for now, where do we store the reviews and retrospectives? You could save them as part of the work item discussion or create a new work item to hold retrospective action points and feedback.
Conclusion
We have seen in this article how Microsoft Team Foundation Server as an ALM tool provides a quick and neat way to start working on your application following the Agile Scrum process.
We need to ensure that all the teams following the Agile SCRUM process need to define and create the following aspects to properly plan and manage their team’s work.
- Use the appropriate SCRUM process template in Microsoft TFS
- Create Product backlogs
- Specifying Sprint schedule and team capacity
- Selecting items for sprint backlog
- Decomposing PBI’s or User Stories into Tasks
- Use Burndown charts to track progress
- Very important to use Taskboard to monitor progress
- Lastly, conduct an effective sprint review and retrospective