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.
Related
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.
Perhaps it is more psychological than programming question:
We use JIRA with Greenhopper in our work, so when I receive new tasks I see them at the Agile Board for current sprint. For every sprint I have a LOT of tasks, after I have fixed, for example five of them I set their state as need test and these tasks go to tester (he has not only my tasks to test as usual). If these tasks are tested and all is ok they closed by tester. The problem is - that I could not see how many tasks I have done. When they are closed they disappear from my Agile board and I see only new tasks there... Imagine - yesterday you have completed five tasks for current sprint, but today chief adds ten more tasks in this current sprint for you.
So: Number_Of_Tasks - 5 + 10 = Number_Of_Tasks + 5.
And thus the Agile Board has no visual progress for me - it grows in size. This is very demotivating
In short: How could I view my done tasks?
You probably have the "Hide Done Issues" button ticked.
Go to Agile > Task (Greenhopper Agile plugin needed)
Above your Task board. One is "Hide Done Issues". Click/Unclick that.
Your Done issues will now be displayed.
Imagine - yesterday you have completed five tasks for current sprint, but today chief adds ten more tasks in this current sprint for you.
As for this, your chief needs coaching. If you are doing SCRUM, then the "chief" (whoever that is) should not add extra work to your sprint. If you finish your tasks early, you should pick some off a teamate who might have run into trouble, or you can test his stuff. The point is to achieve the goals you (the team) have set for yourselves. If everybody is done, then the sprint finishes early. Good for you!
You can finish and replan the next sprint or teamates should pick off stuff from the backlog themselves.
The danger of a "chief" assigning you stuff is that these micro-managers may not have a detailed understanding of what has been done, what is to be done and what is un-tested and might be reopened by a tester.
You can use a Jira query as a filter. The query itself would look like this:
status WAS "Need Test" BY currentUser() AND status = Closed
... yes, quite like SQL. ) Here's the official documentation link.
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)
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.
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.