I am working on a project that is using the Agile template with TFS 2010 and I'm trying to decide when I should assign an Iteration to a task. At the moment I have a bunch of User Stories and these User Stories have been assigned an Iteration. I've then created Tasks for each User Story and linked them.
So, my question is should I assign an Iteration to the tasks even through the User Stories have already been assigned an Iteration? And what should I do about "general" tasks that are not really associated with a User Story? For example, I could create a task that involves updating references for controls or performing a code review. Should these be assigned an Iteration and is it worthwhile managing two types of tasks, i.e. those assigned to User Stories and those that aren't?
Iteration is to be set when your team is committed to work on these tasks. If after reviewing the tasks you decide to defer some, then set the iteration to a later sprint.
An excerpt from MSF for Agile Software Development v5.0 on MSDN:
You can assign the area and iteration fields to most work items based
on a process template for Microsoft Solutions Framework (MSF). You
specify values for the area and iterations fields when you create a
work item or during a review of the product or iteration backlog. If
you defer a work item to a later time, you should change its iteration
accordingly.
And from the work item definition guide:
In the Area and Iteration lists, click the appropriate area and
iteration, or leave these fields blank to be assigned later during a
planning meeting.
Regarding the general tasks, there are special work item for this such as Issue (Agile) and Impendiment (Scrum).
You should definitely check out this resource, it's a presentation by A.Bjork that presents with a way to deal with what you 're after.We tend to assign UserStories to future Iterations, and before an iteration starts, at the time 'planning poker' takes place - we generate & assign the Tasks to the team.Doing so is vital, for TFS to keep a proper tracking of your efforts: the only Work Item where 'hours' are inserted is the type 'Task' - so this is what feeds the Burndown charts that show how effective you work. If you add another Task to a team-member during the sprint, that would be perceived as 'unplanned work' by TFS (simulating an interruption!) and will mess up the calculations for your Team's velocity.Try breaking your long-running Tasks into smaller ones, that shall fit into each sprint. At worst, for example if you have a huge refactoring Task, you can make several child-Tasks assigned to each sprint and then have the umbrella-Task assigned to the last iteration - where your refactoring is completed.Apart from time-tracking (which is solely based on Tasks) you need to also add into your iteration backlog all other work items that are important for the sprint, so you 'll be able to track in the future when each Issue, User Story etc was considered.
Related
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 am trying to understand how to operate Team Foundation Service with scrum methodology. A problem of mine is:
I have a Product Backlog Item and five Work Items. Three Work Items are assigned to the backlog item and are displayed on the "board", so I can move them in between to do, in progress and done. Two other ones are not being displayed on board. Why? How can I assign them to the backlog to be able to see them on board?
This is not supported by the board, unfortunately. For the tasks to show up on the board, they must be a child of either a PBI or a Bug (or any work item that is in the Requirements category).
I was able to accomplish this by creating a new task, then link the backlog item to the task using the ID# as a Parent item (it also works by adding as a Child item as stated by #JamesTupper). After saving, the item showed up on my board. Hope this helps!
I have accomplished this by creating a "Project Tasks" spike to get these types of tasks to show up on the board in their own lane. You can also estimate this SPIKE, if you want to make sure this work is counted in your velocity, but I tend to treat these as "overhead" tasks that don't deliver value, so I don't report on them in our velocity.
If the tasks are related directly to the value you are delivering (for example, you are performing an investigation spike to determine how to estimate a user story) you should definitely estimate that PBI, give it points, and then add those tasks to that PBI.
Either way, adding the tasks as children of a PBI is the way to get them on the board.
If I understand your question correctly, search for the work items that you want to assign to a backlog item. Right click on the task task and then choose 'Link to an Existing Work Item'. Choose parent for the link type and make sure that you know the work item ID of the back log item and enter that in the work item ID. Press ok and then save the task item in the lower part of the web page.
That worked for me.
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.
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 5 years ago.
Improve this question
What is the best approach to handle tasks and user stories that didn't make the end of the sprint in TFS ?
My approach:
Set every task to 'Closed' with the right Reason substate. I copy this task + orginal estimate + remaining hours to Notepad.
Remove the iteration from the user story (so that it will be on the Product Backlog again)
For the next sprint:
Add the tasks from Notepad to TFS as new tasks, assign it to the right user story and set the user story to the current sprint.
This is just an approach. Do you have better ideas or suggestions ?
If you are truly doing Scrum, you will see the only important metric for any team is "Remaining Work". The thing is that many people are obsessed with metrics, statistics, data and loose track of the essence of Scrum.
So keep it simple. In sprint review, simply agree with the PO to when to complete the work and then assign the outstanding tasks to the agreed sprint.
If you want a bit of a productivity boost; then create a query of undone tasks and simply replace the iteration column value to the next sprint and publish back to TFS.
There are two schools of thought:
Leave these and create new ones in the Product Backlog iteration (often the Team Project root). We would leave them and remove the points (for Velocity report), because they represent what our sprint was planned.
Update the iteration to the Product Backlog and deal with them as any other Story during the next sprint. (I would subscribe to this one).
Every team is different with the tasks. If you pick the story again in the following sprint, update the task iteration path and be done. If you don't pick it back up, I would remove the tasks so that you discuss how to deliver on the need in the context of the software as it exists when you do pick it back up. Leaving the tasks on a story for over a sprint has a way of giving us a false sense of security that those are still all the things necessary. I'd rather re-evaluation how we'll deliver on it.
We do the exact same thing you do, but instead of using Notepad, we simply copy the task into a new one & then assign this into the new iteration. By default, the copy-Task is linked to all work items that the original was, as well as the original task itself.The older Task stays in the old iteration & gets marked as 'Closed'.
Maybe i didn't get your problem right, but here is my opinion:
The main idea of undone tasks is that the backlogitem/userstory isn't done. So after the sprint all backlogitems/userstories that are done -> new increment. If a backlogitem isn't totally ready then the whole backlogitem doesn't get delivered, even if its just a few tasks that are left. Just roll everything back (keep the code:) ) and finish the sprint. The backlogitem/userstory goes to the next sprint.
Marking them closed, in my opinion, isn't necessary. Simply keep the remaining tasks, flag / tag them as unfinished, start a new sprint, and apply all tasks with that particular flag as being of the new/upcoming sprint (and if necessary, re-evaluate their times and difficulties).
It is a very common scenario, and we have something on our backlog to create a fit for purpose solution for this, but we have not prioritized it yet over other work.
If you think this is important, feel free to add the suggestion at user voice. We use that site in our prioritization: it is your chance to influence us
Ewald Hofman (TFS Product Group)