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.
Related
I can't work out how to report how many hours per week were recorded by each team member.
For example if a task is 20 hrs, and 10 hours was done last week, and 10 this week, how can I tell how meany hours were recorded against the task each week?
I saw some time tracker plugins, they are not what I'm talking about. They require that the user start and stop time tracking kind of like upwork.
The developers already enter completed hours as they progress the tasks. So if devops remember the dates of each entry then I should be able to query how many hours were added this week, or month, or whatever per user per task.
Here is an excerpt from a discussion we had about it:
Meh, as far as Im concerned:
I make the tasks in notepad usually, so someone can add them to devops.
Someone adds them to develops.
The developers receive them in devops and record their status and times as they develop.
Devops doesnt seem to report on weekly times to us, so we ask the developers to write everything down in notepad or doc and pass us a
list or what they did with times.
We get the developers lists and use them to report to mgmt.
SO
What is the point of steps 2 and 3? May as well just pass the guys
their task in plain test list as I make it in notepad, it will be
easier for them to add their times and pass it back. For us devops is
just extra unwanted work while ever we cant work out how to report on
developer hours.
I think, you can use several ways:
Way 1. Use PowerBi reporting.
Each developer updates work hours every day.
You can use Analytics view to get task history:
Add Completed work to this view.
Connect to Analytics with Power BI Data Connector. Then you can find revisions for each tasks and calculate hour difference
Way 2. Customize your process template.
Add to your process template new work item type (like Time or Activity). Add to these work items new field (like Activity date) or use existing field Target Date. Add to these work items the Completed Work field. Add a custom work item type, Add a custom field to a work item type.
You developers add a new Time work item as child work item to their task and update the Completed Work field. You can use work item queries to see time updates.
TimeTracking in Azure Devops is pain. We have developed our custom solution to track time in DevOps. You can install extension https://marketplace.visualstudio.com/items?itemName=Sense4code.Sense4code-Manday. For more info you can visit also https://www.manday.io/doc/azure-devops-getting-started for more info.
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
Is there a way to create a custom reporting system under the Phrequent section in Phabricator?
In the Maniphest app there is a report feature. However, it only counts total number of task by person or project. My organization still requires total time spent on a project and task.
Inside Phrequent you can already sort by user, however, I need one step further total time spent on a task by user or project. Currently it requires a manual process of totaling each time entry per task by hand.
This is not "yet" a feature and there is no implemented way of doing it right now.
Phrequent is still in its early stage of development and a lot of work remains on it.
The tracking per project is definitely a must feature and is being logged here:
https://secure.phabricator.com/T4853
Finally, the current focus for Phabricator right now seems to be the CI part (Harbormaster and Drydock) so the roadmap does not mention incoming work in the short term:
https://secure.phabricator.com/w/roadmap/
but only in the long term:
https://secure.phabricator.com/w/starmap/
On a side note, I considered using phrequent but I believe it's too far from being production ready right now so using other time tracking system seems to be the only viable solution.
Hi trying to implement TFS for my team (18 members).
I made two branches
1) Main branch
2) Dev branch
We are using Agile.
So there is a sprint every week. And on every Thursday i merge changes from Dev to main Branch.
Each developer works on different user story. if he completes a task and check in all changes (5 files). change set (e.g 62) is generated. But tester reported a bug while unit testing. Developer fix the error and check in 1 file. it generated a new change set (e.g 63).
Problem is when i am merging user story's change to main branch i am confused with which change set to move. (62,63....)
what i do is compare whole project. which is headache some times.
Can some one suggest better way. Or i am missing something? any blog that can help
Thanks
If you have a single DEV branch, that implies that you should be merging the whole branch and all changes to MAIN (not cherry-picking, which is what you seem to be describing).
If you want the flexibility to merge only changesets relating to certain stories/bugs, then you should adopt a different branching pattern such as branch by feature.
You need to change the way that you build and deliver software in order to deliver more successfully.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
What you are describing with picking changesets will consistently and continuously reduce the quality of your product.
If you implement a good definition of done and get your guys working in a team rather than independently you should have working software at the end of each sprint. Just before the Sprint review (just in time) you should merge everything from dev to main maybe using a changset as a watermark. If you have stories in your sprint that go towards features that are not ready yet then you should hide them behind feature flags and ship.
If this sounds to hard, or something that "will not work here", or you think "or product is more complicated than that", then you are likely suffering from significant technical debt and you need to pay that back untill you give your Product Owner the choice to release everything at the end of every sprint.
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.