When I go to my dashboard in TFS (2018) and add a burndown chart widget, the chart contains no data. Is there something I'm missing? The sprint contains resolved/closed backlog items. Thank you
For reference:
Have you Set the team capacity and activity?
Seems you didn't set the team capacity and activity correctly. Also you need to specify the Activity and Effort, Remaining Work for each related work items. See Capacity planning and Sprint planning for details.
A burndown chart only applies to a sprint that's in progress, and the chart should start from the first working day (Spend time on tasks/bugs etc).
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.)
We are following Scrum process and I want to calculate how many PBIs were actually considered or added during each iteration of release? For e.g. on day 1 of Iteration1 I have 10 PBIs and added 5 more till last day of Iteration 1. So I should get planned PBIs as 15, no matter how many were removed, Done or moved to backlog / next sprint.
I am able to get work items in my C# application and tried to loop through WI Revisions but I am not getting it correct.
How to achieve this either through TFS WIQL or TFS APIs?
We use Greenhopper/Jira for planning our Sprints.
A coworker want to see the changes that happens during a sprint: what tasks got, done; What tasks got added or removed from the sprint.
Is there a nice way to do that?
The only think we came up so far is to export the sprint context at the start of the sprint and at the end and compare it.
Limitations of that approach are:
If we forget to do such an export, we loose the capability to compare, since there is no way to turn the time back.
We have to juggle excel files or similar
Just go to your Agile Board, switch to Report mode (press key "3"), select the "Sprint Report" from report dropdown and right under select the sprint you want to get information about. This report shows all information you need to know about your sprint. At the top you will see the minified burndown chart, then list of completed issues and issues which were removed from sprint while you were working with it. Issues with asterisk are those which were added to a sprint after it's start. See the following link for more information https://confluence.atlassian.com/display/AGILE/Viewing+the+Sprint+Report
Based on this answer the model for the TFS 11 burndown chart is for tasks that a children to stories.
How can I display a burndown chart of the currently opened bugs during a sprint without having to create subordinate work items for them?
The way it is intended is that you add tasks as children of the bug as soon as the bug is added to a sprint. These tasks will drive the burndown. This is the same for Product Backlog Items and it is very simple through the web ui. The estimation data in the bug itself will be represented in the release burndown.
Should you want the bug itself to function as a task, you can either:
Use a task workitem to log bugs. This is very common for bugs found for work that is ongoing in the current sprint. It's just a bit of extra work to achieve 'done'.
Update the work item definition for bug to have the proper states and fields, and add it to the task category. The process is mostly described in this question.
You should also keep in mind that bugs found for work that was done in a previous sprint should only be picked up in the current sprint during the sprint planning meeting, or when it is critical to fix it as part of the current sprint. In the first case, treat it as just any other PBI and break it down into tasks. In the second case, go fix it immediately, don't bother about the burndown, the bug is critical and should be fixed now.
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.