I am trying to recreate my own tfs with similar features. The additional fields for an item are Effort(hours).
Is this an addon or does this require change in flow via visual studio? I think I have an idea but I forgot how is technology to edit TFS called and where in visual studio?
The Effort(hours) in Task work item type is existing in AGILE and CMMI process Template. If you use Scrum template, you can change to the Agile template for your project.
You can use Burndown in tasks if you want to track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.
We simply use number of tasks for our burndown measure. Usually you do something like actual hours or ideal hours, but this was good enough for us and apparently interesting enough to need some clarification.
There is a user voice about using the effort estimates work in the Scrum TFS template for your reference (The response from TFS Product Group):
The “Effort” field on the Product Backlog Item is meant to be any unit
the team decides they want to use. Some teams use “Story Points”. Some
use “Ideal Days”.
The Remaining Work field on the Task, is the same think. It is
whatever the team decides it to be. The only thing our tools expect is
that it is reduced as you work on it, so we can provide a burn-down.
If what you are looking for is a way to capture the original estimate
(complexity) of the task, then you’ll need to update the Task work
item type definition and add that custom field yourself.
If you need to custom field, please refer to Add or modify a field for details.
And this thread for your reference: Scrum - When do you Estimate the Effort for Product Backlog Items?
Besides, you can also try the Addons : eg TFS Time Tracker
Related
I am working on scrum with VSTS(Visual Studio Team Services)
I am able to add estimated effort to backlog items as well as estimated hours to different tasks.
I was wondering if there is a way that allows me to add the actual time taken to finish a specific task. So that I can later have a report or so to see the difference between estimation and actual in order to enhance the team estimation.
Not in the SCRUM Template. That template is all about remaining time. I believe the AGILE Template will let you enter original estimate, remaining time and time spent. So perhaps look into that.
Failing that, you could use an add-on. Have a browse of the Visual Studio Marketplace
This one looks like it might work for you: TFS Time Tracker
Completed Work field is only available for the Agile Template. I believe you can still create a custom template to be able to configure fields in the default template (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-field).
However, VSTS is probably not intended for time tracking. You can try and use time sheet extensions to VSTS.
For example, TFS timesheet (https://www.teamexpand.com/product/tfs-timesheet) allows inputting hours directly from a Work Item tab and generate detailed reports that show how many hours were spent to complete a task with a day-by-day breakdown. It also allows to keep track of actual time vs. estimated time.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I hope that somebody with more experience (bad or good) can help me out here: I am setting up a project tracked in JIRA. The whole process with user stories, documentation, sprints, workflows, bamboo and fisheye integration, etc. is set up. But now I have a rather administrative question:
Where should developers log their work in meetings, such as stand-ups and retrospectives and for writing specifications (detailed descriptions of user stories to come)? I really cannot see what makes sense here, as I need the developers (obviously) to track this work, too. As far as I can see, the possibilities are:
Separate PROJECT-ADMIN JIRA project with simple, non-agile issues
Separate and parallel sprint with admin tasks
Administrative tasks for each sprint
Other versions??
Option 2 seems very hackish, as parallel sprints are just in a beta-stage for the JIRA agile (former Greenhopper) module. Option 3 seems a bit much work to setup for each sprint, and I am not sure, how this influences my velocity (ideally, I want to see the possible amount of story points that can be achieved in a sprint). Option 1 seems the most reasonable to me, but others have advised against it, unfortunately, without offering a solution. I haven't really looked into option 4, as IMHO this is very similar to option 2.
I couldn't see any best practices anywhere, so I would very much welcome any advice from more experienced people. Thank you very much.
We use Tempo to log our billable work against JIRA issues, whether a single Epic for a small project or individual tasks for a larger project. For non-billable work we have a single project where people can optional log work, and we also use it for planning our time. So option 1 is the closest there. We could also have categories for different work logged in Tempo and handle this case that way.
So I face this exact issue with my team and this is what is working for us (for now) YMMV.
Our current structure is that we have a Roadmap type project (call this Planning) where all issues come into at first. Thereafter we create issues in related product projects (call this Product).
In the beginning of the lifecycle, any meetings, scoping, etc will have sub-tasks created and the time will be tracked on Planning. Once scoped and scheduled for work a new issue is created on Product and linked to this original issue.
Once the Product issue is assigned and the dev is called to any meetings whilst this issue is in a sprint we will create a sub-task on Product and assign the time. If the issue is not in a sprint we go ahead and create a new sub-task in Planning and assign the time there.
When then also have a project where we do Housekeeping type work. So if we need changes to JIRA, Stash, Confluence we will create the issues here. We will then create a new issue on Planning, link the issue and schedule that accordingly.
We have a meta project that acts as a bucket for anything that doesn't fall into the other categories which we sift through every now and again to identify if we need to create separate projects.
I have created a custom field that rolls up all the times of any linked issues found on the Planning board
Have a look at the Twitter blog Visualizing Epics and Dependencies in JIRA by Nicholas Muldoon maybe this can help you in some way too.
One caveat we are still exploring the best way to do this. Each environment is different and what works for us might not work for you.
I have faced the same issue trying to track team member hours that are unrelated to the project or related to the project but not to a specific story or task.
Initially we went with option 3 & had several administration tasks that persisted across sprints. While this was relatively easy to implement it failed for us as we had team members that sat across multiple projects & as a result these administrative tasks that resided in each project were impossible to manage / report on for these team members.
In the end we went with what you have described as option 1. By creating a separate project with "non task related" issues such as Planning Meetings, Technical Issues & Client work then installing the JIRA Misc Time Log & Report Extensions plugin we could provide users with an easy means of logging times without having to change projects or boards (since the plugin adds a dropdown menu to the top navigation).
The plugin then allowed us to get reports on where team members we logging time off project regardless of how many projects they worked on concurrently.
I was having the same issue, and I know some time has passed since the moment this question was posted but maybe this is useful for a lot of people:
Tempo has a dedicated feature for that thing you want to achieve and is called Internal Issues. not to be confused with Internal activities.
You can go there by navigating to Config>System and then click on the add-ons tab. Then scroll down to the Tempo section in the menu on the left bar and there you'll find a link that reads Internal Issues. There you can create the issues. Please keep in mind that before creating internal issues you have to create the tasks, for instance "Sprint Planning" or "Retrospective" in the project without assigning to anyone, just to the project.
When your users go to log their time for those "Internal Issues" they go to Tempo > Timesheets and then click in the upper right button that reads log work. There, in the right menu they'll see the "internal issue" option where they can pick those internal issues you previously created and log the time that the team spend on SCRUM Ceremonies.
I'm a configuration manager currently learning about TFS functionality. We've chosen the CMMI process template and my 'problem' is that I don't understand the checkin / work item association permissions. For example, it seems I can associate my checkins against:-
Any work item type including the less obvious ones like Derived Requirement or Risk
Any work item type that isn't actually even assigned to me
Any work item type at any life cycle state (including Closed)
Is there any way to customise this or have I just not read the right chapter in my book yet? :-)
Thanks
I dont know an policy which checks all of your requirements, but try the "Work Item Query Policy" described here.
The policy works like described
Associates a work item from the specified query with your check-in. You configure the policy by selecting a team query from your team project.
Now you can specify your query that you can solve 1 and 3.
Note
The policy will be available if the Team Foundation Server Power Tools August 2011
are installed.
Additionally all clients (Developers) have to install the Team Foundation Server Power Tools August 2011 too.
At the moment i dont know a way for 2, only to write a custom policy like described here.
EDIT
Based on the comment from DaveD, the second requirement (only assigned to me) is solved via
'Assigned To = #Me' condition.
In visual studio, one can create "tasks" by inserting comments like this:
//TODO: Make me a sandwich before looping.
These tasks can then be viewed under the View > Task List menu. But these tasks are entirely independent from Team Foundation Server.
It would be extremely useful to be able to automatically create a new Team Foundation work item when a TODO task is added, so that the work item can be assigned, commented, attached to, linked, and associated with check-ins, etc.
Anyone know if this is possible?
My suggestion - even if it was somehow possible:
Don't do that :)
//TODO: is very lightweight, you can add/remove/modify those lines as you like with no impact besides being source controlled.
TFS work items are much more heavyweight and process oriented (only so-and-so many state changes are allowed according to a process template).
Synchronization and keeping track would be a nightmare. Therefore I think nobody I know of does it.
We use:
//TODO: for developer comments/reminders. - Internal/developer only
WorkItems for Bug/Feature/Task tracking (Inprogress/Complete/etc.) - Team/developer/tester only.
Help Desk Request for End User visibality. - All/End Users
I don't think they should be mixed as they server different purposes.
I completely agree that turning TODO items into work items is the wrong way to go.
But considering this as a tool capability exercise I think it can be achieved.
You can define a dummy build with a custom build activity in it.
Here is a series of blog posts by Ewald Hoffman teaching how to customize Team Build.
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
Part 5 discusses how to automatically increase assembly version with each build. He does this by including a custom activity in the build which scans through code files to catch a text pattern (in this case the assembly version xml tag) and update it.
The same approach could be used to catch TODO items (for the sake of the exercise) and work items could be created through TFS API.
Again, I do not recommend doing this but this technique could be used to solve other similar problems.
We're currently using Visual Source Safe and BugNet and looking to migrate up and away from VSS. I've been pushing for either SVN ( a) we're an ASP.NET shop, b) DCVS is not an option - no matter how much I like Hg ;-) or TFS. Well we finally got a new dev server, so I talked the boss into installing TFS on it (30 day trial). In the meantime, we had started experimenting with FogBugz. We really like FogBugz for about 80% of what we want to do, and the other 20% is probably stuff that we don't know what we want.
I'm pushing for TFS because it allows for IDE integrated (mostly) everything.
He's pushing for FogBugz because he can group tasks by customer and then project and manage everything from one dashboard. (which means I lose most of my IDE integration - no huge loss I agree)
Does TFS support a single dashboard that would span all our solutions (in this case each solution is a full app that we sell to a vertical market client) and let us assign workitems to each solution-spanning-group?
So for instance I think we envision something like this:
PROJECT1 - Bugtracker and workitems
PROJECT2 - Bugtracker and workitems
PROJECT3 - Bugtracker and workitems
CUSTOMER1 - Deployment schedules, required features, specific notes (Uses PROJECT1, PROJECT2)
CUSTOMER2 - Deployment schedules, required features, specific notes (Uses PROJECT2, PROJECT3)
CUSTOMER3 - Deployment schedules, required features, specific notes (Uses PROJECT1, PROJECT3)
Hopefully that makes sense. naturally it's more complicated than this but I think I've given the details enough to paint a picture.
I offered the option of creating dummy projects per customer but he doesn't like that and it doesn't really give us the single dashboard view that we're hoping to end up with (and that FogBugz as we've sorta implmented things does do now).
Has anyone got a good suggestion on a management app that would accomplish what both of us want?
EDIT: since I got some good responses (albeit not what I wanted) I'm going to close this for now. However, I think this is something that would be a good thirdparty market and/or a feature in an upcoming TF release. Feel free to post with more ideas if you come across this later.
TFS allows you to have multiple Team Projects. Each is effectively a root folder for source control. However, you can move files/folders between projects in source control, and the Work Items are global (shared across all Team Projects). For Work Items all the projects do is provide a level at which you can filter out work items (so you look at bugs only for this project, etc).
So Team Projects allow you to nicely compartmentalise your projects, but they are only virtual compartments, with few limitations on moving items between those compartments.
The only problem I've found with multiple Team Projects is that you have to branch a folder (and cannot branch a Team Project) so if you wish to make a branch that spans several projects you have to have several branches, which means severwal workspace mappings and several merges for each operation.
For customers we simply added a custom "customer" field to our work items that allowed us to relate a work item to a spacific customer.
When you look at work items you can then apply SQL-like filtering (e.g. TeamProject=#Project AND Customer="BiggsAndCo" AND WorkItemType="Bug" would find all the bugs reported by BiggsAndCo in the current TeamProject)
There are a lot of third party add-ins for VSTS to enhance the TFS experience (thankfully, as raw TFS provides very basic and clumsy UI), and you can use the API to write your own tools to query the TFS database too, so you shouldn't have too much of a problem getting a dashboard thta you find useful. You'll need to do some searches to see if the solutions out there match your requirements though.
One way to do this is would be to have a single team project that covers all of your solutions and use subfolders in source control and items paths on your work items to separate feature requirements, bugs, and so forth by project.
It's the customer specific information across a subset of projects that you'll probably need to do some customisation in order to report on since you have a many-to-many relationship that TFS work items don't support out of the box.
Hope that helps