My team is using TFS2017 and we have some 100+ past iterations (sprints) in our backlog/board. (I'm talking about Past, Current & Future iterations). We're only interested in 5-6 most recent Past iterations and scrolling to the end of the list is generally annoying.
Is there any way to change the sort order of the past iterations to descending?
If this isn't possible, is it possible to create a new group/item/list/whatever besides Past, Current and Future, called Old iterations (or something like that)?
Thanx in advance.
To reduce the number of iterations on the "Past" section you can configure in the team settings to see only the iterations of the current year.
Press on the Gear icon when you on your team page --> Work --> Press on "Change" near the "Backlog iteration".
After that, you will see only the iteration from the current year and the scrolling not will be so annoying...
Related
Is there a nice way in TFS to see all the Stories/Tasks I have worked on and what day I committed/closed them out and maybe did associated check-ins for them. I want this because I work on many different client projects and need to track my time in a time sheet and sometimes forget what I did each day if I don't fill my timesheet out daily.
There is no out of box feature for this. A similar feature request on VSTS User Voice can be found here: User Activity Stream.
As an alternative solution, there is an TFS Timetracker extension in VSTS Marketplace which you can try to use. This extension will allow you to record the time you spend on every work item and generate a report.
I believe TFS is unlikely to enable this capability in the nearest future.
You can try out time sheet extensions to TFS.
For example, TX Chrono (https://www.teamexpand.com/product/tfs-timesheet) allows to log hours directly from a Work Item tab in TFS and get a work time day-by-day breakdown over the selected period (So you can make a report where you'll see hours spent on a particular WI, how many hours were spent each day, WI current state, etc.)
I have been using TFS to track my backlog items and I am now trying to write a query to see how long I took on particular tasks in the last 7 days. So Far I have this query:
Work Item Type = Task
AND State = Done
AND Closed Date = #Today - 7
AND Area Path = #Project
AND Assigned To = #Me
and have added the column "Closed Date" which shows the time work stopped on this item. But I cannot get any information as to when work started on the Task
Feels like the data should be there as on particular tasks it has the following kind of information:
Is this possible? I don't mind extracting the data to Excel to analyse.
The reason I ask is because I would then like to go on to compare the amount of hours assigned to a particular task and compare it to amount of hours actually taken to help my predictions of time taken in future.
It's a pretty simple query actually.
Here's what I'm using.
(Work Item Type = User Story
OR Work Item Type = Bug
)
AND State <> New
AND State <> Removed
Simply include the Activated Date, the Resolved Date, and the Closed Date in the displayed columns. The time between Activated and Closed is your total cycle time.
My team uses Resolved as a "pending deployment" status, so comparing Resolved to Closed allows us to determine how long it takes to get an item from "done" to "in prod".
TFS is not intended to be a time tracking tool. You could query the work item history with the TFS API and check the timestamps on when the state transitions occurred if you really wanted to.
Agile projects don't focus on how long individual tasks take -- they focus on how much value the development team is providing over the course of a set period of time. One thing might be estimated low, one task might be estimated high, but it ultimately doesn't matter as long as the team delivers what they committed to deliver.
It's a good practice to track Cycle Time for a team to discover areas for improvements (for User Story level, yes)
It's not good that user must go Excel to calculate Cycle Time. I can't use diagram Azure Devops tools with this calculations and its not automated.
Cycle Time widget don't shows results for several teams and it's not flexible tool, so it's not enough
I have done quite a few Gantt Charts in Tableau, but this one is stumping me.
I am trying to create a project type Gantt chart that displays the project level due date at the top of each grouping. This should show the due date from the case and the duration so far. That works fine until I attempt the next part which is to allow the consumer to click on that bar and have the tasks roll down with each of their project and in many cases actual durations. (scheduled start and finish if not completed and actual start and finish if it is)
The problem is that Tableau wants to make the Project an aggregate of the tasks' durations. I need to show what we specced the project out to, then the actual task break down so we can see where we are misjudging our estimates. Also would like a dropline for today that goes to x axis and one for when project is due that goes to the pane axis for the project. Yes of course there are multiple projects being plotted across the departments as well. Has anyone ever done something like this in Tableau? Any idea how I can get this to stop summing the tasks and use the project projected duration?
Thanks in advance,
Karen E. Hannum
We recently finished our first couple of sprints and some questions were raised to which we don't quite know the answer.
Both questions are related to: what should we do with backlog items, tasks and bugs which are not completed when the sprint ends? And how will a certain action influence a burndown or velocity chart?
If we have a 20 day sprint, my guess was that we should start on day 1, stop on day 20, leave one day for the next sprint meeting (day 21) and start the next sprint on day 22.
Let's say we have a PBI which has 3 tasks. One task is Done, one is In Progress and one was put back to To Do. The PBI has an effort of 6. If we move items in or out of the sprint during the sprint this has an influence on the Sprint Burndown and the Velocity chart. But once the sprint ended, and we move these items, does it still affect the charts? Or how should we handle such items? Should we close the PBI (set it to Done, even though it's not) or just move it and leave the tasks that were done in the previous sprint? Should we set all tasks to Done, even though some aren't? Each task has been worked on, so hours were used. We need to keep track of those, or at least, the velocity chart should still be OK.
A similar question rose for a bug. We added a Testing state, so instead of setting the state to Done, the developer sets it to Testing, so the test team knows which PBI's or bugs to test, and sets it to Done once it's completed. If a bug arises from a PBI, we close the PBI and open a bug for it. But if it's a bug, and it's not fixed, they reopen it. Either by setting it to Approved or Committed, but what happens with the efforts that were assigned to it? If the bug is not fixed when the sprint ended, should we set it to Done and open a new one, or just move it to the next sprint?
Scrum has been slightly revised and clarified over time; the latest version is more or less specified in The Scrum Guide (2011)
The Sprint Planning Meeting is part of the Sprint and it typically performed on the first day of the sprint (Day 1). Day 20 Will contain Sprint Review and Retrospective. Day 21 is actually Day 1 of the subsequent Sprint.
Regarding your question about the unfinished Product Backlog Item (PBI): Your goal is to establish a velocity for your team over time. CONSISTENCY is key to this. So most importantly, you should establish a way of doing it the same every Sprint. I see teams handle this is different ways; You need to determine if you actually delivered the Sprint Backlog Item based on what got done. If the value wasn't delivered, then you can leave it as not done and optionally update the final work on the tasks. You can also put a note in the history and/or description of the Sprint Backlog item about what was accompished and the acceptance criteria achieved. If the value of the item was delivered to some degree then you might make a similar note and count the item. You need not be exact about the points covered in the Sprint since they will average out over time, so you just need to use your judgement. Whatever is not done can be made a Product Backlog Item and prioritized accordingly. Your Product Owner may decide to put it lower on the Product backlog depending on the value of what was not finished in it. When the PBI representing the unfinished work, you will create a new set of tasks for it (you might copy the ones that were not completed from the Sprint in which they were not completed to save time). What is also important here is to discuss how things went and how you can handle this moving forward during your Sprint Review and Sprint Retrospective so your team can adjust accordingly.
Regarding the Bug, you might consider handling it similarly to the PBI for planning and prioritizing and Done / not done; your team needs a definition of done; if this includes testing, you should consider it Done only after testing. If it is not done then again you should handle that in a consistent way. Out of the box, the Scrum 1.0 version of the Bug work item has a state named Committed that indicates that the Bug is ready for testing, so you shouldn't need that testing state. Once it passes testing, it goes from Committed to the Done state. You can find the Process Guidance for the Scrum 1.0 template on the Microsoft site. It is more or less the instructions for how to work with the template.
I made a mistake when entering my sprint plan in Jira/Greenhopper: it turns out we have a little bit more capacity than planned.
This happened the second day of the sprint, but if I add the extra issues after the beginning of the sprint, the red 'guideline' starts from our original estimate.
Is there a way to avoid this?
I've encountered the same desire to 'adjust' the guideline in the sprint report a few minutes after starting a sprint.
I've solved it in the following manner:
Go to the 'Plan' tab on your Agile board
Set the start time of the sprint after the the timestamp of your adjustment
Check the sprint report (it should be fixed)
As I understand the question the problem that you are facing is that the red guide line is drawn from the amount of work entered at the start of the sprint down to the end date for the sprint.
When you add more work to the sprint after the first day the guideline doesn't move. This can't be changed. See the thread here for discussion on that topic.
I think the logic here is that you should have all of your work defined and estimated at the start of the sprint and if the estimate increases after the first day then that should be because the tasks are more complex than first thought, not because you added more work.
I agree that it would be good if there was a new 'line of best fit' between your current remaining work and the end date to show the new level of velocity you would need to reach, but that is not supported.
I've added stories before to an iteration, and the burndown just ticks up with the additional, to show what else has to burn down. Greenhopper will represent the uptick an adjustment to the estimate, since it was added mid-iteration, but the remaining work is increased and then continues to burn down appropriately.
Abnormally terminate the sprint and restart it could be an option here. Since you already have the bulk of the items selected the sprint planning meeting for this could be in a very small time-box. Since you abnormally terminate you definitely can skip the sprint demo, you may want to have a short retrospective if you want to discuss how the problem/error happened, but I doubt it. You could be up and running with a new sprint in a few hours.
A late added task can be forced to be considered at the begin of the sprint using a workaround: log a minimum amount (1minute, e.g.) of work at the sprint first day.