Take a look at TSWA - Team System Web Access. It's easy to set up, uses the same groups and permissions as TFS and you can access it from anywhere inside your network using Internet Explorer. You can give access to people who don't have Visual Studio installed. This makes it nice for bug tracking and review by interested stakeholders. It's light weight enough that some of the developers in my group prefer it to opening VS to enter time or look at new tasks.
Something fun about the tool is that if you open a work item and scroll down to the bottom of the details tab, you'll see a little diagram of all the states the work item has gone through. You can see in a moment how many times the bug has gone from development to test, back to development and back to test (ugh!).
The best part is that it's probably part of your Team Foundation Server package so you probably already own the software. Enjoy.
Monday, August 30, 2010
Saturday, July 17, 2010
Unassigned Work Items (Tasks)
Most people fear the unassigned task. In our implementation of Team System (TFS), I added a name to the list called unassigned. It's led to a more self managed motivated team and I have no regrets. This works great if you have a self motivated team or a PM who pays attention. Yep. That's an OR.
How did I do it? I still use active directory to drive my dropdown in the assigned to field but I added a user called unassigned. This gets around the problem of TFS requiring something in the assigned to field if you're driving it off of active directory.
"But if the work item is unassigned nobody will do it!" Did I mention that most people fear the unassigned task? I do not. Here's why. If people only claim enough bugs and tasks to last them the next few days or weeks they are motivated to get those done so they can claim the fun tasks or bugs before someone else does. Another advantage is predictability. If a person has claimed 3 months of work and takes longer than expected on the first month of work, nobody else is working on the on the work items that are claimed but not being done. In this case, high priority features and bugs aren't being taken care of in the right order.
As a project manager, I can look at the list of unassigned tasks and see which ones are high priority to I can let the team know that those are the next things to work on. We manage priority by using the priority and iteration path fields, but if there's too many priority 1 items in the current iteration a little verbal communication goes a long way.
Something else that drives everyone outside of my team crazy is that I let my high performing teams choose their own tasks and bugs. I help scope out the work at a high level, create the basic tasks and load the planned bugs. The team adds tasks where needed and fixes bugs as they're identified.
As time goes on, the team takes more and more ownership of the project and project goals. I believe that allowing people to self manage this way is a large part of the reason. They're software developers - creative responsible professionals. Creative people like to have ownership in a creation and like to feel that they're contributing more vision than a few lines of code. The project is always better for it when the team participates in the vision.
The end result of having unassigned tasks and asking the team to self manage is that I have each team member looking at the project and work item list with an eye to the big picture. Each team member is concerned that we're getting the right things done first. They let me know if they see issues. The extra sets of eyes are very helpful.
How did I do it? I still use active directory to drive my dropdown in the assigned to field but I added a user called unassigned. This gets around the problem of TFS requiring something in the assigned to field if you're driving it off of active directory.
"But if the work item is unassigned nobody will do it!" Did I mention that most people fear the unassigned task? I do not. Here's why. If people only claim enough bugs and tasks to last them the next few days or weeks they are motivated to get those done so they can claim the fun tasks or bugs before someone else does. Another advantage is predictability. If a person has claimed 3 months of work and takes longer than expected on the first month of work, nobody else is working on the on the work items that are claimed but not being done. In this case, high priority features and bugs aren't being taken care of in the right order.
As a project manager, I can look at the list of unassigned tasks and see which ones are high priority to I can let the team know that those are the next things to work on. We manage priority by using the priority and iteration path fields, but if there's too many priority 1 items in the current iteration a little verbal communication goes a long way.
Something else that drives everyone outside of my team crazy is that I let my high performing teams choose their own tasks and bugs. I help scope out the work at a high level, create the basic tasks and load the planned bugs. The team adds tasks where needed and fixes bugs as they're identified.
As time goes on, the team takes more and more ownership of the project and project goals. I believe that allowing people to self manage this way is a large part of the reason. They're software developers - creative responsible professionals. Creative people like to have ownership in a creation and like to feel that they're contributing more vision than a few lines of code. The project is always better for it when the team participates in the vision.
The end result of having unassigned tasks and asking the team to self manage is that I have each team member looking at the project and work item list with an eye to the big picture. Each team member is concerned that we're getting the right things done first. They let me know if they see issues. The extra sets of eyes are very helpful.
Saturday, June 12, 2010
How do I use Areas and Iterations?
I don't know what do do with them. Can I get away without using them? It's just one more thing to fill out for each work item.
You could. After a few years of tracking projects with Team System, you'd probably regret it even if you're a one person shop. Areas and iterations are intended to be used for product and time categorization. They're a tree structure, so if you set them up right you can get a ton of flexibility out of your system in exchange for a little work filling out the fields.
Use area for product. Make your area tree structure mimic your application menu structure. This assumes that you have a seperate team project for each product or application you have. We set our Area up to track project/subproject, but in retrospect I would have rather used area for product. We have a complex systems with many menus and the area tree structure would have handled that well. I would have made a separate field called Project and created a list of projects to drive that field off of.
Use iteration for time. Track versions and iterations here. This makes it easy to plan which version and which iteration or timebox you're going to do work in. If you don't develop iteratively, no problem. Use only the top level of the tree structure for versions.
Create a field to capture project name. Call it "Project Name" or something that makes sense to your organization. Make it a dropdown list containing your projects and sub projects.
When you're done, you'll have something that looks like this:
You could. After a few years of tracking projects with Team System, you'd probably regret it even if you're a one person shop. Areas and iterations are intended to be used for product and time categorization. They're a tree structure, so if you set them up right you can get a ton of flexibility out of your system in exchange for a little work filling out the fields.
Use area for product. Make your area tree structure mimic your application menu structure. This assumes that you have a seperate team project for each product or application you have. We set our Area up to track project/subproject, but in retrospect I would have rather used area for product. We have a complex systems with many menus and the area tree structure would have handled that well. I would have made a separate field called Project and created a list of projects to drive that field off of.
Use iteration for time. Track versions and iterations here. This makes it easy to plan which version and which iteration or timebox you're going to do work in. If you don't develop iteratively, no problem. Use only the top level of the tree structure for versions.
Create a field to capture project name. Call it "Project Name" or something that makes sense to your organization. Make it a dropdown list containing your projects and sub projects.
When you're done, you'll have something that looks like this:
- Team Project - System
- Area - Subsystem/menu/submenu
- Iteration - Version/iteration
- Project (you create this field) - project/subproject
Saturday, June 5, 2010
Shared Resources and Searching Across Projects with TFS
Projects in Visual Studio are a great way to group items and, similar to builds, you can pull information from different projects with your queries. Don't let anyone tell you this isn't so. Our organization almost implemented a single project for everything we do at the advice of an expensive consultant. We reconsidered and out at the last minute on that plan. Whew! Saved. After a year and a half, we're all still glad we made the decision. We have 3 to 4 projects going on at once with teams of 4 to 20 people. The projects are usually wildly disparate, so it's nice to be able to only see one project at a time - most of the time. Here's how you do it:
Remove this: Team Project = @Project from your query.
Now you can see across the organization. You can see where your shared resources are spending time - and if that other project manager is using up all the resources [shaking my fist ineffectively]. You can query bug rates vs. development hours across the organization. With Team System 2010, there is another level of grouping for projects so this should only get more powerful.
Remove this: Team Project = @Project from your query.
Now you can see across the organization. You can see where your shared resources are spending time - and if that other project manager is using up all the resources [shaking my fist ineffectively]. You can query bug rates vs. development hours across the organization. With Team System 2010, there is another level of grouping for projects so this should only get more powerful.
Sunday, May 30, 2010
I've been told "You don't need access to the TFS warehouse"
Wrong. You're a PM. You of all people need access to the warehouse. You need read only access to query the warehouse only. Don't let them give you read/write. Nobody should write to the warehouse but the warehouse. Making changes in the warehouse would ruin the beauty of the warehouse - it gives you snapshots in time of your Team System metrics so even if something changed today you can go and see what state it was in yesterday or the day before, or the week before.
But they told me "The TFS warehouse is a production system and you have other ways you can access the information, like MS Project".
Nope - still wrong. Wrong times nine. What can you do with the warehouse that you can't with MS Project? Lots. Tons. All kinds of things.
But they told me "The TFS warehouse is a production system and you have other ways you can access the information, like MS Project".
Nope - still wrong. Wrong times nine. What can you do with the warehouse that you can't with MS Project? Lots. Tons. All kinds of things.
- Use Team System as a time entry tool.
- Create dashboards for requirements, development and test that update automatically on a daily basis.
- Find out how many bugs are created each day and why - find issues in your process.
- Find out how many bug fix hours you're spending per development hour per project.
Saturday, May 29, 2010
Why won't Johnny enter his time (how to get time entry information out of TFS)?
Because it's a pain - that's why. He has to enter it 3 different places using 3 different tools. Wouldn't it be nice if he only had to use the tool that's already integrated into Visual Studio? The tool that tracks his work items all the way back to his code check-ins?
Why not just use the time entry system you have? It works, right? Because the metrics you get out of your time system probably don't integrate with MS Excel, SQL Reporting Services or get put in a warehouse for easy reporting. Because the rest of your project metrics are in Team System and the one bit of information you need to make them complete are somewhere in a 10 year old classic ASP application with a crazy clunky interface.
Wanna try? Sure you do. It's easy.
Open SQL Management Studio and connect to your favorite TFS Warehouse. Don't have access to the warehouse? Get it. Connect to the warehouse and run this:
/*Create a temp table to hold values from the two queries needed to fetch this information*/
CREATE TABLE #TFSTime(
Person nvarchar(256)
,Change float)
/*Declare variables common in both queries*/
DECLARE @StartDate Datetime
DECLARE @EndDate DateTime
DECLARE @TeamProject int
/*Set the date range and project*/
SET @StartDate = '7/16/2010';
SET @EndDate = GETDATE();
SET @TeamProject = '25';
Insert Into #TFSTime
/*Insert tasks where the user entered a value in completed work and created the task at the same time*/
SELECT P.Person
,WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork]as Change
FROM [TfsWarehouse].[dbo].[Work Item] as WI2
Inner Join [TfsWarehouse].[dbo].[Work Item History] as WIH2
on WI2.[__ID] = WIH2.[Work item]
Inner Join [TfsWarehouse].[dbo].[Person] as P
on P.[__ID] = WIH2.[Changed By]
Inner Join [TfsWarehouse].[dbo].[Date] as D
on D.[UTCDateTime] = WIH2.[Date]
Where
WIH2.[Team Project] = @TeamProject
AND WIH2.[Revision Count] = 1
AND WIH2.[Date] > @StartDate
AND WIH2.[Date] < @EndDate
AND RIGHT(WI2.[Work Item],2) Like '-1'
AND WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork] <> 0
ORDER BY WIH2.[Date]
Insert Into #TFSTime
/*Insert time from tasks where the user updated completed work*/
SELECT P.Person
,(WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork]-WIH1.[_Microsoft_VSTS_Scheduling_CompletedWork]) as Change
FROM [TfsWarehouse].[dbo].[Work Item] as WI1
Left Outer Join [TfsWarehouse].[dbo].[Work Item] as WI2
on WI1.System_ID = WI2.System_ID
AND WI1.System_Rev = (WI2.System_Rev-1)
Inner Join [TfsWarehouse].[dbo].[Work Item History] as WIH1
on WI1.[__ID] = WIH1.[Work item]
Inner Join [TfsWarehouse].[dbo].[Work Item History] as WIH2
on WI2.[__ID] = WIH2.[Work item]
Inner Join [TfsWarehouse].[dbo].[Person] as P
on P.[__ID] = WIH2.[Changed By]
Inner Join [TfsWarehouse].[dbo].[Date] as D
on D.[UTCDateTime] = WIH2.[Date]
Where
WIH2.[Team Project] = @TeamProject
AND WIH2.[Revision Count] = 1
AND WIH1.[Revision Count] = 1
AND (WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork]-WIH1.[_Microsoft_VSTS_Scheduling_CompletedWork])<>0
AND WIH2.[Date] > @StartDate
AND WIH2.[Date] < @EndDate
Select SUM (Change)as Time_Entered
,Person
From #TFSTime
Group By Person
Drop Table #TFSTime
Things you might want to change are highlighted in yellow. Replace the team project with your team project number (query the project table to see what that is if you don't know).
---------------
Updated 7/19/2010 - I updated the query to account for times when a person creates a task and puts time in the completed work field at the same time.
Why not just use the time entry system you have? It works, right? Because the metrics you get out of your time system probably don't integrate with MS Excel, SQL Reporting Services or get put in a warehouse for easy reporting. Because the rest of your project metrics are in Team System and the one bit of information you need to make them complete are somewhere in a 10 year old classic ASP application with a crazy clunky interface.
Wanna try? Sure you do. It's easy.
Open SQL Management Studio and connect to your favorite TFS Warehouse. Don't have access to the warehouse? Get it. Connect to the warehouse and run this:
/*Create a temp table to hold values from the two queries needed to fetch this information*/
CREATE TABLE #TFSTime(
Person nvarchar(256)
,Change float)
/*Declare variables common in both queries*/
DECLARE @StartDate Datetime
DECLARE @EndDate DateTime
DECLARE @TeamProject int
/*Set the date range and project*/
SET @StartDate = '7/16/2010';
SET @EndDate = GETDATE();
SET @TeamProject = '25';
Insert Into #TFSTime
/*Insert tasks where the user entered a value in completed work and created the task at the same time*/
SELECT P.Person
,WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork]as Change
FROM [TfsWarehouse].[dbo].[Work Item] as WI2
Inner Join [TfsWarehouse].[dbo].[Work Item History] as WIH2
on WI2.[__ID] = WIH2.[Work item]
Inner Join [TfsWarehouse].[dbo].[Person] as P
on P.[__ID] = WIH2.[Changed By]
Inner Join [TfsWarehouse].[dbo].[Date] as D
on D.[UTCDateTime] = WIH2.[Date]
Where
WIH2.[Team Project] = @TeamProject
AND WIH2.[Revision Count] = 1
AND WIH2.[Date] > @StartDate
AND WIH2.[Date] < @EndDate
AND RIGHT(WI2.[Work Item],2) Like '-1'
AND WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork] <> 0
ORDER BY WIH2.[Date]
Insert Into #TFSTime
/*Insert time from tasks where the user updated completed work*/
SELECT P.Person
,(WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork]-WIH1.[_Microsoft_VSTS_Scheduling_CompletedWork]) as Change
FROM [TfsWarehouse].[dbo].[Work Item] as WI1
Left Outer Join [TfsWarehouse].[dbo].[Work Item] as WI2
on WI1.System_ID = WI2.System_ID
AND WI1.System_Rev = (WI2.System_Rev-1)
Inner Join [TfsWarehouse].[dbo].[Work Item History] as WIH1
on WI1.[__ID] = WIH1.[Work item]
Inner Join [TfsWarehouse].[dbo].[Work Item History] as WIH2
on WI2.[__ID] = WIH2.[Work item]
Inner Join [TfsWarehouse].[dbo].[Person] as P
on P.[__ID] = WIH2.[Changed By]
Inner Join [TfsWarehouse].[dbo].[Date] as D
on D.[UTCDateTime] = WIH2.[Date]
Where
WIH2.[Team Project] = @TeamProject
AND WIH2.[Revision Count] = 1
AND WIH1.[Revision Count] = 1
AND (WIH2.[_Microsoft_VSTS_Scheduling_CompletedWork]-WIH1.[_Microsoft_VSTS_Scheduling_CompletedWork])<>0
AND WIH2.[Date] > @StartDate
AND WIH2.[Date] < @EndDate
Select SUM (Change)as Time_Entered
,Person
From #TFSTime
Group By Person
Drop Table #TFSTime
Things you might want to change are highlighted in yellow. Replace the team project with your team project number (query the project table to see what that is if you don't know).
---------------
Updated 7/19/2010 - I updated the query to account for times when a person creates a task and puts time in the completed work field at the same time.
Subscribe to:
Posts (Atom)