How Microsoft DevDiv uses TFS - parts 4 and 5

Release planning

In previous posts, I talked about how we use TFS to implement processes.
In this, we will talk about how we planned the release.
In the Feature work item we added the “Planning” tab:

Scale up:

We asked people to perform an approximate estimate (estimated cost) for each functionality in the work item. Then, we moved them to a table with a rating, as shown below:

This Excel spreadsheet is directly related to TFS. It is important to note the following:

1. This estimate (like all other data) comes directly from TFS. And this is great, since all estimates were entered independently of each other, but they can be pulled out into a single document, which makes planning easier.
2. We ranked all the functionality from top to bottom.
3. We added some logic to the table in order to be able to compare the total load with the potential of the team. Teams are highlighted in yellow if they use their reserves more than 70%, and red - if more than 100%.

This approach gives us the opportunity to quickly understand what can and what can not be done without the need to mess around with the tables. This helped us to find thin spots and plan by changing the priorities of the functional in order to achieve a comfortable load level. For example, we have moved some volumetric functionality down to allow several small functions to get into release.
To be honest, as time passes, it looks like a video game. We called it the game of yellow and red, because it was fun to see how much we can reduce the yellow and red colors! :)
Next post: how we controlled the progress of the work.
Gregg Boer. Link to the original .

Monitoring the progress of work

Before starting the conversation about the control over the performance of work, it will be useful to consider the life cycle of the functional described in the previous post . The image below will be the starting point for this publication.

The picture below shows the “Progress” tab of the “Feature” type work item.

Simply put, in front of you is my status report. As a person working on functionality, I needed to fill out such a report once a week. There was no need to use email or create documents, I just updated the fields in this section.
When the Developer Division decided to implement the functional development team model, as well as all the quality characteristics (in the original, Quality Gates), we decided not to interfere with the management processes that the development teams took for themselves.
Some used the “waterfall” method with MS Project, others - SCRUM, someone - Excel or glued stickers, and someone - just drew on the board. It really didn't matter to the unit as a whole, as long as you update the information in the section shown above.
The “Progress” tab has become a subdivision standard for providing the minimum set of information needed for weekly communication.
Looking at this bookmark, you might think that this is too primitive and simple game. However, the fact is that it has become a very useful reporting tool. And this will be discussed in detail in subsequent publications.
Let's take a closer look at all the elements from this figure.

1. Key Dates - we tracked four key dates: the beginning and the end of the work on the functionality and two intermediate target dates. IMPORTANT NOTE: before the implementation of the functional, the team had to fix the control date No. 1 and assess the occurrence of the control date No. 2, as well as the end date of this work. Upon the occurrence of the control date No. 1, the team fixes the control date No. 2 and estimates the date of completion of the work. It seems to me that this model worked well.
2. Percentage complete (Percentage of completion) - just the expected and completed work on all functionality. Since we did not interfere in the management processes within the teams, we demanded that they clearly understand how much was done and how much was to be.
3. Risk Level (Risk Level) - the first field, as a classic traffic light, in the risk indicator. Green = we meet deadlines, Yellow = there is a risk of deadlines, Red = we broke deadlines. The second field contains text comments.
4. Additional important dates.
5. Text notes about the status of work.

In the next post, I will show you how we used the information described above to control the simultaneous implementation of multiple functionality, as well as the lessons we learned.