Want to build a report showing each team member's percentage contribution per a completed Sprint.
We break up the work in Tasks and assign a Remaining Work value to indicate the time needed. The problem then is that remaining value is clear or decreased as the sprint progresses.
Have been looking for a way to find the original remaining value, so I can use it for reporting post the sprint. All in an effort to try and build a relation between originally set Effort and Actual hours.
Any assistance would be appreciated.
First I have to say this, as a Professional Scrum Trainer with Scrum.org, we highly discourage the breakdown of effort to the individual team member as part of standard reporting. Where scrum is concerned, the individual contribution is of little consequence outside of the team context, and inside of the team we feel that team members should be able to openly discuss the perceived value added by other team members as part of their Sprint Retrospective.
Secondly, because TFS can't register multiple users being assigned to a task, nor support the trackign of hours spent by multiple team members on the same task, your report will either be incomplete at best, cause additional administration overhead in most cases and may even cause team members to not work together at worst.
That said...
TFS tracks all assigned and saved values for work item fields. Using the API it's easy to iterate through the work items and retrieve their previous Revisions. As an alternative, the API offers asof work item queries which allow you to track what the values of a workitem were on a specific date. This information is also store in the TFS datawarehouse, if you are using it, aggregated at the daily level.
But if you need accurate tracking of time spent, the only reliable way is to add the Completed Work field to your work item type definition:
Completed Work
The amount of work that has been spent implementing a task. You can specify work in hours or in days. There are no inherent time units associated with this field.
Reference name=Microsoft.VSTS.Scheduling.CompletedWork, Data type=Double
Task, Bug
This is required to cover cases where the original estimate was lower than the actual time spent, remaining work would in that case remain the same, or even increase, while a team member had spent time on that item. without also tracking CompletedWork, this data is lost.
The Agile and CMMI template use this field by default. The Scrum template doesn't, you can guess why based on my initial cautions.
Related
In docs.microsoft article there is a statement:
The forecast tool ignores Scrum items set to Committed or Done and
Agile and CMMI items set to Active, Resolved, or Completed.
And so the tool includes in current iteration's forecast such items:
really moved to the current iteration and really active and resolved;
and next few iterms really moved to the next iteration;
WHY they are ignored? They don't complete and the team need time to complete ones!
I don't understand how to use this tool?
What kind of process proposed to use?
Thanks a lot!
You are correct that the forecast tool ignores the In Progress Items whether they are shown or hidden. Regarding why they are ignored, I'm afraid it's by design. Once your team has completed a sprint or two, they can use the team velocity to forecast how much of the backlog they can finish within the upcoming sprints. This doesn't include In Process Items, but for Proposed items.
If you have any suggestion for DevOps, feel free to submit a suggestion at website below:
https://developercommunity.visualstudio.com/content/idea/post.html?space=21
So I am trying to write a query that will show me completed bugs, of completed PBIs, that were handled within the same sprint. In other words, bugs we introduced with new functionality, but also closed before finishing the Iteration.
The issue is the hard reference to Iteration Path. What I would like is a variable like #ThisIteration, and I would place it both of the highlighted spots. This way I could return all of the Bugs and PBIs that were resolved with in the iteration for all time.
I assume this just doesn't exist within TFS Queries, so I am looking for work arounds, or clever solutions, like WIQL, etc.
Thanks,
Devin
Based on your requirement: "write a query that will show me completed bugs, of completed PBIs, that were handled within the same sprint"
The query you created should works. For the Iteration Path we can only use the macro #CurrentIteration in on-premise TFS. In VSTS you can use the #CurrentIteration +/- n to offset the iteration. Please see Query macros or variables and Query for items based on a sliding window of team iterations for details.
Note
Feature availability: The #CurrentIteration +/- n macro is supported
for VSTS only, and only when run from the web portal.
Besides, you need to adjust/modify the query based on the Bugs working as.
If Bugs are managed with requirements, then the Bugs and PBIs are
in the same level. So you can use Board Column field to filter...
If Bugs are managed with tasks, then the Bugs and PBIs are not in the
same level. Filter by Board Column will not work. So you need to use State field to filter...
WIQL would be the same...
Just like the title says, I would like to know if there is any way in TFS 2013 Update 4 to query a whole week-long activity for a certain User (a team member of a certain project) across multiple projects.
An example scenario will be as follows :
User_A is a team-member in Project_1, Project_2, and Project_3.
On Day_1, he performs some work in Project_1 (development : 2 hours, testing 1 hour). He also performs another work in Project_2 (bugfixing : 3 hours).
On Day_2, he continues his work in Project_2 (bugfixing : 2 hours). And then due to some circumstances, he is required to solve an urgent issue in Project_3 (3 hours).
And so on until Day_5, shifting back and forth through multiple projects.
Now, our PM would like to know the details of his work during this week (from Day_1 until Day_5).
Is it possible to generate data, perhaps through a query in TFS Web Access to aggregate data for
User_A in a given timespan ?
Thanks.
There are a number of questions in here and I will try my best to answer them all:
Query Across Team Project in Web Access
First, you can query in Web Access across multiple Projects by just removing the "Team Project" part of the query.
You can even create charts based on this data...
However for anything more complicated you should use the built in Reporting Services tool and the Data warehouse that comes with TFS. If you don't have it installed then you can add it.
http://nakedalm.com/integrate-reporting-and-analyses-services-with-team-foundation-server-2013/
This will gave you access to much more powerful reporting but it is much more complicated to configure. You get a cube (multi-dimensional data) and a warehouse (lists) that you can query to your hearts content both across team project and across collections.
Time Tracking in TFS
TFS is an effort management system and is not good at time management. While you can get a query to show you the amount of time applied to a Task you can tell when that time was applied without some serious giggery pokery. In TFS (well the MSF templates anyway) you store "Remaining", "Completed", and "Original Estimate".
So today I have a task that I completed 4 hours and tomorrow it will have a value of 8 hours in the completed field.
So did I complete 8 today? No, I only added 4.
What if I decided that it was only 3 the day after I entered the data? Can I fix it? No,
I could go on and on with the issues and caveats for trying to track time in TFS, however, if we just assume that it is not possible (or at least more effort than it is worth) then we are left with finding another solution. (Yes, I know there are third party tools that plug onto TFS and do time sheets or other stupid stuff, but they all have issues.)
I recommend tracking course grained time against a Project in a tool is separate from TFS, that is designed to collect this information. I have used Harvest and Freshbooks but there are other time sheeting systems out there. Do not integrate it with TFS. I have never once seen that work effectively and there is no value in it.
Is there value in tracking time - Not actually asked but it goes to the crux of the issue
The only demonstrable value I have ever seen in collecting time sheets is a) if you are billing your customers for that time, or b) you need to understand capex vs opex against a project. If both are true then a simple Project in Harvest with two tasks, one for Feature work and one for Maintenance work, will be sufficient and way simpler to manage.
I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when the sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.
I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.
I have these versions set up in Greenhopper:
Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.
Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.
Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.
Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.
v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.
During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.
I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.
We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.
See my feature request to Atlassian and Vote for it.
"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"
https://jira.atlassian.com/i#browse/GHS-11139
If you are using TFS 2005 or 2008, how do you user iterations and areas?
Do you create an area for specific parts of the application you are building?
Here is an interesting article on areas and how the TeamSystem team uses them:
http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
But, i'm even more curious about iterations and I would be grateful if you could show me few concrete examples.
Do you create iterations based on milestones or based around certain functionality?
What happens when you finish v1, how do you manage v2 or updates to v1?
We are using MSF Agile template.
We use areas to represent product lines.
Since we use SCRUM, the iterations in TFS are used to define our release cycles, and the sprints within those release cycles.
Backlog items are assigned to release cycles and work items are assigned to eash sprint to ensure those backlog items are completed.
After a release, it is perfectly fine to add bug fixes/updates to the backlog while working the next version at the same time.
The Iteration and Area Paths are what you want them to be. Its how you can describe your project in space and time. An easy example are as follows:
Area Path (Space) - can be used to describe the parts of your system/project. Say you create a TeamProject for a GUI application, some areas will discribe its modules (Data Input, Reports, GUI, Printing, etc...)
Iteration Path (Time) - describes Versioning or Release Cycles of your project. On company that I worked for used release versions as their iterations (major, minor, build, revision). It helps track the work items to mark what iteration it was expected to be completed by. We had a static TBD iteration which was the default for all work items created. Management would decide later where to target that work items and assign them or close them.
I assume you are using iterations as part of MSF Agile, or some other type of Agile methodology. If so, in general, you figure out how much work can be completed by your team over the next n weeks. In general, we used 3 weeks, but your iteration length may be different.
How you determine the items for the iteration is generally based on priority, which should be based on market/business impact (hotness of item) and ease of implementation. The impact score is the heavier weight, but you should consider ease of implementation in your score as you may have a few "bang for the buck" items.
The rule, with Agile, is features that cannot be completed get dropped. You NEVER extend an iteration date.
This should answer the milestones versus functionality question. It is neither. You base an iteration on time. It is time boxed. This way you can figure how optimistic your team is an adjust next iteration to get more accurate on estimates. If you base an iteration on functionality, you will always miss dates. The same is true for milestones.
NOTE: If you are talking waterfall, the rules can be based on milestones and functionality, but with Agile, time is king.
Now to areas: This one is more subjective. One way of dividing into areas is grouping use cases. I like this method. But, when it comes to user interface, you can also create areas for particular forms, etc.