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.
Related
I have a portfolio set up for my Project in Jira. It contains 6 or 8 epics and there are varying numbers of Jira tasks associated to each epic.
The Portoflio Scope view shows the epics and the tasks under each epic but the progress bar displayed for each epic or it's linked tasks does not show progress, even for epics where 90% of the tasks are marked resolved or closed.
All tasks have Original Estimates, Remaining time and those that are resolved, fixed have time logged against them.
I cannot find anything useful int the Jira Docs for tracking progress. I presume this is down to some smal config option or some feature of the epics or tasks but I cannot for the life of me work out what it might be.
We are using the cloud version of Jira.
Any ideas?
OK, so we found the reason behind my issue. By default the portfolio Scope view was showing epics for my project with the 2 releases I was interested in. There is a More option on this filter and under that was Completion date.
By default this completion date seems to be since the beginning of: Current Sprint. This meant that all tasks marked resolved or closed were excluded from the list of tasks under the epic on the portfolio board...hence, no progress.
I'm not sure why tasks listed as completed under the current, active sprint were not listed based on the default Completed filter though? Maybe it is because the portfolio was set up based on a Project rather than a Sprint Board?
Anyway, changing the completion date to something else then meant the completed tasks were included under the epics and I am now seeing lots of green progress bars!
Using TFS Cloud (myproject.visualstudio.com), there are no Estimated, Completed, Remaining fields to add time to a bug. Do we really have to create a TASK work item basically called 'fix - bugname' for every bug, just to log how long each took to fix?
I appreciate on larger bugs this makes sense, but some are spelling mistakes or other minor problems.
This then doubles the number of work items in lists for all?
any suggestions?
Well, having looked into this, the quick answer is yes.
The benefits of doing so are simple. A TASK is the 'smallest' thing you can do in TFS, and it is always assigned to one person.
Given this, by creating tasks to do the 'work', you can at least see who did the work and account for it (without looking at the history of an item).
You can also 'bounce around' the assigned to for the actual BUG, e.g. to get someone else to verify it, or leave it assigned to whoever 'owns' that bug, while fixing it can be assigned to others (the tasks).
If you are using Agile or CMMI template the bugs will not appear on the task board.
Ideally, you need to create tasks to represent the work that you or team members are doing. For instance you need to create development task for fixing the issues and a QA task for testing.
Also you should keep an eye on the statuses of the bug in parallel to the task. i.e. if the developer is working on the fix the bug should be assigned to the Developer and it should be Active and the development task also should be active as well.
Once the development work is completed the the developer can close the underlying task and Resolve the bug and assigned it to QA for testing. If everything goes well the test engineer will close the testing task and at the same time he/she should close the bug as well.
Technically yes. What we've decided to do (purely for simplicity and not to bog us down with even more user stories in TFS) is we create one user story per sprint and name it: "BUGS - SPRINT#". Under that we will have tasks that track the work/time spent on bugs.
We also name the tasks by category. For example, if there is a bug in the UI, we name it (example) UI - arrows not reappearing.
Not sure if this is the best way to do it, but it accomplishes effort tracking and keeps TFS clean.
I take it that you are using the "Microsoft Visual Studio Scrum" template. The fields in the work items vary based on the template you are using.
For bugs in the Scrum template, we usually cover the effort in the "Effort" field.
We are Using Visual Studio 2012.
This is the way we are handling this situation. We have created a user story “ Resolving, Re-testing bugs.” Every iteration developers who have to fix bugs create a ONE task for all bugs. The developer adds comments to each and every bug resolved, and update time accordingly.
QA person also adding a ONE task for the iteration for re-test bugs. QA person update his task accordingly for each and every bug.
All Developers and all QA personal create child tasks for the same user story.
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)