Your message is highly valuable for us. One of our experts will follow up with you within 1-2 business days to discuss your request or to inquire for additional information if needed.
Infopulse continues reviewing TFS and its features. Previously, we showed how TFS could be applied for project planning and monitoring and talked about TFS essentials and its basic structure. In the following blog post, we’ll talk about work scope estimation with TFS.
TFS Estimation Fields
Release plan preparation has to be based on the prior experience, understanding of the development speed and complexity estimation.
TFS has a dedicated field for Effort (Complexity) at the levels of User Story, Feature, and Epic. Considering prior experience and requirements, the team can analyze the total complexity of implementing specific functions. The results of the User Story estimation would be similar to those as shown in Picture 1. In this example, we can see how User Stories are allocated on the complexity axis and then grouped into relevant units that can be chosen by each team independently.
It is important to note that Effort (Complexity) is estimated only in relation to other User Stories, and is not measured in working hours. Units of measurement, in this case, are really a matter of preference, and may range from regular units like “Story Points” to some extraordinary ones, like “snakes”, or “lottery tickets”.
Picture 1: Relative estimation of the User Story
Upon estimating separate User Stories, Effort values can be grouped on the Features and Epics levels. As soon as the team size is fixed, complexity estimation in Scrum becomes regulated by timeframes only. Here the team serves as a carrier of the prior experience with a fixed development speed. By fixed development speed, we imply that the team is able to complete a certain amount of “Story Points” during a cycle of a fixed length. However, this assumption may become a bottleneck when the team is formed from the ground up or is fundamentally changed before the project start.
“Velocity” (development speed) is a statistically defined, albeit somewhat relative value, which measures how fast a team can complete their work. On contrary to some opinions, Velocity is neither a delivery rate, nor a bare minimum. It helps to form a release plan with a room for adjustments and within a certain success probability level.
Picture 2 shows the number of Story Points that were completed by the team within the project delivery during approximately nine months. If we analyze the amount of the work delivered, we can see that after an adaptation period at the beginning of the project the team delivers no less than 110 units per sprint. Nevertheless, one shouldn’t set the bare minimum at 125 units and expect the team to deliver it, motivating them with a “You Can Do It!” approach. Velocity is more of a prediction than of a strict delivery plan.
Picture 2: Velocity – delivery rate
Teamwork Scope Estimation
In many real-life scenarios, when the team is new and has no experience in working together, it is impossible to plan release based on the Velocity. In such cases, planning should be based on the uptime of such activities as development, testing and documenting.
Each part of the requirements can be estimated in hours required for their implementation. For this reason, each User Story delivery is divided into separate tasks. See the example in Picture 3 below.
Picture 3: List of tasks in the User Story field
Additionally, TFS has an Activity field at Task level, according to which the tasks are distributed among the groups inside the team. Thus, by estimating teamwork scope, we can consider separately the number of resources required for the frontend, backend, and testing. The Activity field, just like many other TFS fields, is a custom dictionary where we can add or extract values. An example of an Activity Field in an average project can be seen below in Picture 4.
Picture 4: Activity Dictionary at the Task level in TFS
At this stage of scope estimation, tasks and time required to implement them are already known. To balance the tasks with the time available for the team, TFS has a Team Capacity management option. This value is estimated per one sprint level and shows an approximate number of hours committed by all team members, as well as the types of activities they are involved in. A specialist can perform different roles, be a part-time employee, or may take a vacation; and all these values can be specified in Team Capacity Management so that they could be taken into account during the planning stage.
In the following example, we’ll show a common sample of Capacity field and will fill it in. Picture 5 shows settings for a team of 6 people, including an analyst, a designer, a testing engineer and three developers. As we can see, John Doe and Korben Dallas work part-time and are active only three hours per day, while Samwise Gamgee is a technical leader and has to perform Review besides the regular development job. The rest of the team works full-time. As a rule, one hour per an eight-hour working day is allocated for the meetings while the remaining time is contributed to performing ongoing tasks.
Picture 5: Team Capacity
Now everything is ready to distribute User Stories among the sprints while considering the time required for particular activities instead of the relative complexity values.
TFS automatically determines the balance between the Remaining Work (a value in hours required for all tasks within a sprint) and available Capacity. This ratio is always shown on the operational page of the sprint. The Work section shows the percentage of the sprint time set for regular tasks.
Some common cases are shown in Picture 6 below. For instance, at the beginning of the sprint, it is recommended to save at least 10-15 % of the time for the possible changes and new requirements. At the same time, we can see that testing work scope exceeds the sprint schedule. In this case, the team may negotiate different options with the customer, such as reducing or extending the sprint, finishing QA during the next sprint or involving more specialists for testing, etc. Most importantly, there is an obvious indicator showing the need to carry out such managerial decisions. The capacity is balanced when every team member is in the green zone and has some extra time, and the total aggregated figures of activity types are in the green zone too. These figures should be monitored and supervised on a regular basis.
It’s worth to mention, that it is easy to shift User Stories between the sprints. You can move User Stories to any iteration or to Backlog with all accompanying data and analyze the capacity changes within the sprint with the help of the right-click menu. By deleting bulky User Stories and adding smaller ones, you can optimize the sprint capacity while considering the specifics of each team.
Picture 6: Analysis of a Team capacity at the beginning of the sprint
Read more about work assignment and task scheduling in the third part of the “Project planning and monitoring with Team Foundation Server” article.