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
Related
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.
I am filling the product backlog for a new product with user story PBIs. As I write, I realise that some PBIs are dependent on others being completed first. I cannot use the order of the backlog because it gets changed by others depending on client requirements. I want it to be obvious that one PBI depends upon another being completed first. Inter-PBI links are possible but it's not clear what a link between PBIs represents.
What is the best way to get TFS 2012 (in the cloud) using the SCRUM template to represent PBI dependencies?
Does anyone use hierarchical PBIs or tags for this purpose?
Thanks in advance.
There is a WI link type for Predecessor/Successor. This is how I typically do it. It doesn't make it super-obvious, but the information is captured somebody just has to go to the WI Links tab to see it.
I would recommend that you get all of the people competing for priority in the backlog to appoint a single Backlog Owner who understand the dependencies ( sounds like you). That person can then order the backlog taking into account both customer priority and dependency.
I have in the past added a Customer priority field to the PBI & Bug to allow the Sales\Customer Services guys to order that field to their hearts content in excel.
That way they are not interfering with your order but still providing the influential and valuable customer order.
I will be using TFS 2012 and I am confused as to how to setup work items for one job where there are dependencies to the steps needed to get the job completed. For example, if the job first needs to get feedback from the end user, then a developer needs to build the base classes. After the base class work is completed then another developer needs to build the UI components. After the UI is completed then the tester needs to test the work. This job requires multiple people, including more than one developer. Each step cannot be started until the prior step is done. Should all of these steps be different work items or all in one work item? If multiple work items, how do you have the work item show as ready to work on for the next person when the prior work item is completed? If only one work item, then how do you handle the steps for multiple developers? This is one example. There could be the case where we have five developers all dependent upon each other before they can start their own work.
It sounds like you're trying to fit TFS into a formal waterfall process. It probably isn't going to be a good fit in terms of creating Gantt charts for you. In TFS you can use the hierarchy of user stories and tasks to accomplish half of what you want. For the other half you can create the appropriate link type between the tasks.
However, TFS isn't going to give you a Gantt chart like view for them, it isn't designed that way. If you really want to manage projects in this fashion, I'd look at integrating TFS with MS Project and/or Project Server.
As an aside, I would strongly consider just having those people talk to each other rather than relying on a tool.
As long as your performing an agile process your on the right track. Sprints should be based on PBI deployment, not completed tasks. If you find yourself pushing a PBI across multiple sprints, you may want to break-up your PBI. It is better to do this than keep wondering if your team is getting things done, since a group of tasks are moving into a new sprint. Getting a PBI to completed at the end of a sprint should be a key goal for an agile team.
Assign all the tasks needed to complete the PBI. Tasks should be created by the team together. This will help decide how to break down the tasks. I would break down the tasks mentioned into independent tasks based on functional groupings (UI, Business Model, ect). The art of this is to not break them down too much. The team will decide this for themselves. (remember to keep agile and let the team make short-term mistakes if it will help long-term: estimation, scope, quality, ect.
Assign QA tasks with unique names for each PBI. Don't use QA for the task name, it can become difficult to prioritize on the Board view. If you have a test team, let them create there qa tasks. Agile is agile (the team is the team).
The other main key point I learned was don't move on to tasks until the PBI has been planned completely, don't move on to sprinting until the tasks have been planned completely. This will help ensure that once your are sprinting, your not making decisions for that sprint in the middle of the sprint.
I hope this gives you some pointers.
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
We are using VS 2010 and TFS 2010 with the Microsoft Scrum Template.
We use the Team Queries for the Current Sprint like the Sprint Backlog query.
The problem is when we move to sprint 2 the "Current Sprint" still points to sprint 1.
Is there a way to to tell TFS that we are now currently in sprint 2 and have the queries use a variable to run against instead of hard-coding the sprint?
For example: If you look at the screen shot below you will notice that the definition of the query uses a variable called "#Project" for the team project. Is there a way to have a variable for the sprint?
Tom,
What you are asking for is not available in TFS 2010. There are not even dates on the iterations, so TFS does not know what the current iteration is.
In TFS11 (vNext) we have added the dates on the iterations. It now knows in which iteration you are, and this is also reflected on the backlog page in web access. In the preview version that is out now it is however not possible to add a filter clause to your queries to filter on the current iteration (something like #CurrentIteration). We have heard strong feedback to add this in the product before it ships. It is also very high on our wish list, but we need to fix other things first before we can ship.
You can add this request on User Voice. If the idea gets lots of votes it makes it easier to build a case that we need to put this in. But we cannot promise anything.
Ewald - TFS Program Manager
Almost all answers here say that you either need to wait until Visual Studio implements #CurrentSprint token or to change all existing queries manually.
I found another great practice that might help you which is explained here:
http://intellitect.com/transitioning-between-sprintsiterations-with-tfs.
Try to create a “release” called “Current” and move the specific current sprint under it. It's much easier and quicker than dealing with queries every time you start a new sprint.
You could modify the work item query programmatically: http://www.ewaldhofman.nl/post/2010/03/09/TFS-SDK-2010-e28093-Part-6-e28093-Replace-text-in-all-Work-Item-Query-Definitions.aspx
I've only ever read documentation/guidance (links unavailable at the moment), that said at the start of a new sprint there are a few various steps you need to take in TFS, e.g:
create the new sprint/release nodes
set the applicable PBI work items' iteration to the current sprint
set the applicable PBI work items as committed
update all the "Current Sprint" queries to reflect the new sprint number.
I've never seen documentation on doing the last step list (or any of them) in a hands-off (automatic) way. That said, I'm not suggesting it's not possible, just stating that I've never seen guidance on how to do it, but have seen plenty of guidance on doing it manually.
You could use a plugin called TEK workitem. TEK workitem is a Visual Studio extension for TFS that allows bulk edit of query definitions, besides other features like open in Visual Studio workitems and queries from a Hyperlink, delete Workitems from Visual Studio UI, etc.
You can download a demo from Visual Studio Gallery: TEK workitem
I am pretty recent to TFS Scrum 1.0 but this is what I do.....
I am currently managing my sprint dates outside of the template
I use the 'Current Sprint > Query’s' to give myself and team quick access to the queries on the current sprint.
When I finish a sprint and want to increment to the next sprint and have the queries under 'Current Sprint' point correctly I do the following:
Edit each query under ‘Current Sprint’
Right lick and select ‘edit query’
You may see an error dialog if you have changed the hierocracy of your iterations. OK to click through to the query editor.
Set the value of ‘Iteration Path > Under’ by selecting the correct sprint from the drop down (populated with your iterations.
Save the query and bob’s your anty…. Queries will display you current sprint. Just repeat each iterations.
Hope this helps....
I found in TFS 2013 that if you uncheck the sprint/iteration the one with the earliest dates get assigned to current automatically. If you want to keep the old one visible, move the dates out a year or so and it drops to bottom of list, but out of scope.
This is TFS online 2017
Step 1) Settings-> Work->Default team settings
Step 2) and then 'Default Iteration'->Change
Keep in mind that next time you might be starting in Step 2. So Step 1 is optional.