We are using TFS 2013 and the latest Scrum template.
From my understanding, bugs and PBIs are at the same level in the backlog.
But how to handle bugs/issues, that are found during a sprint in a "ready-for-test" PBI?
When a developer finishes a PBI, he moves it in the Kanban-Board from "In Progress" to "Ready For Test".
Then our Testers test this PBI (user-story) using Microsofts Test-Manager. When they find an issue, the create a new bug. The advantage of doing so, is that we get a good documentation of the observed problem automatically in the bug work-item.
But from my point of view, it's not a bug. It's simply an unfinished PBI!
The main problem with this approach is, that it's cluttering up the Kanban-board and the backlog very quickly.
What is best practice in that case?
Is there somewhere a guideline / whitepaper for this scenario?
Or maybe we are just using the Test-Manager in the wrong way?
I completely agree that what you have is an unfinished PBI. Where I think things may be going wrong is when the developer effectively 'hands the PBI over' for testing.
Handover, or sign-off, or 'passing the baton' are unhelpful in an agile or Scrum way of working. I advise that focus should always be on moving a single PBI to done. Nothing else matters. Only when that PBI is done, should the developer start work on another PBI.
So, I'd encourage the developer to do whatever it takes to get the PBI tested immediately before he/she starts work on anything else. If any issues arise, the developer addresses it immediately. That way you avoid the situation you describe.
Create a new task within the PBI. To me, a bug has to be found in 'done' work - while the story is in development, it is just another piece of development that needs to happen before the story is done.
(I have duplicated my comment into an answer as people seem to agree).
We created a new type of work item called Story Bug, which is based on Task. That is a bug in a story to difference it from a regular bug found outside the work of a story.
We also created for it a slightly different workflow: new -> in progress -> bug resolved -> bug in QA -> done.
The QA opens the story bug in the new state. Then the developer moves it to in progress and when he Finnish working on it he moves it to bug resolved. Then the QA takes it and moves it to bug in QA where he checks that the bug was fixed. If the bug was fixed the QA moves it to done; if not he moves it again to new.
Related
I've had three items assigned to me for the current sprint, two of them categorized as "blockers." The third item, in 'done status,' had a requirement change today.
I checked on what "blockers" mean, and they are things preventing you from getting a task done, right? So how can a goal itself be a blocker?
Also, I've been forced to do a lot of context-switching this week in the past. This is due to support for a couple of projects. However, it keeps me from settling into the blocker tasks.
By the way, I did get one blocker task reclassified as "major" due to effectively going over the Scrum Master's head. However, it was a non-customer-facing pilot project that I had been pulled into a call on. So both of the blockers came about this way.
The third project had a scope change due to a bug discovered (not my code), which affected me.
I'm not clear how to handle all this. Any ideas?
The word 'blocker' does sometimes get used as a way to describe a very high priority task.
e.g. This ticket is a blocker for another team, so we must get it urgently fixed.
I agree this can be confusing!
When a task (Task_1) is a 'blocker', it means that without solving it, another task (Task_2) in the team cannot be completed.. so 'blocker' tasks usually have a high priority.
So you can imagine both tasks have to be done in series, like in an Airflow DAG:
Task_1 >> Task_2
I'm unclear how the workflow/life cycle of a product backlog item should work - particularly when it comes to who should update the state and when that should happen.
Previously, we used TFS only at the task level, so anything that had to happen, the programmers would submit their code for a task, mark it as "DONE", then as a tester I would either find it was done correctly and mark it as "COMPLETE", or find some error or incomplete implementation and return the status to "TO DO".
Now we've set up an actual structure of Features, PBIs and Bugs, and tasks underneath but I'm still unclear on a few things.
For example:
Project Manager approves PBI and changes the state from NEW to APPROVED. It gets assigned to a sprint and the programmers mark it as COMMITTED, then write a number of tasks underneath. When they finish their tasks, they mark them as DONE.
How should I (the tester) know I can start testing that PBI? Are the programmers supposed to mark the PBI as DONE? And then I test it and if it doesn't pass, I turn it back to COMMITTED? If it passes, do I just leave it as DONE? (I find it confusing how there is a DONE for tasks and bugs that is different from DONE for PBIs).
Or do I look at the task level and see that all the tasks marked as DONE, and change them to CLOSED if they pass my testing or back to TO DO if they don't pass. I then only change the PBI to DONE once all the task testing has passed and all the tasks are marked as CLOSED? (one issue I have is sometimes the task is so programming-specific that I wouldn't know how to verify to change it from DONE to CLOSED).
Technically a "Project Manager" should not be involved in the process at all.
The PBI, as with everything on the backlog, is owned by the Product Owner. The Product Owner is accountable and responsable for the contents, and everyone else's understanding of said contents, of the backlog. However the Product Owner may not physically do anything and can delegate to the team.
So... The Product Owner, and the Development Team, should be the only ones changing states or editing Backlog Items. (caveats exist at scale).
Specifics:
As the Development Team is responsible and accountable for getting things to Done then they get to mark it as done when the whole team agrees that they have met the DOD.
Anyone can add something to the bottom of the backlog, but only the Scrum Team can change it and move it around.
The Product Owner approves the work, bit any member of the Scrum Team can proxy that approval and change the state.
There should not ever be a state after Done.
The whole team (analysts, coders, testers, operations) all work on a PBI in the Committed state. The work item stays committed until it is Done, or abandoned.
Note: You can find out more by reading the Scrum Guide: http://www.scrumguides.org/
Our team is going to start tracking our roadblocks (or impediments) better but I see that there are Impediment work items and there is the Blocked dropdown in a task. When would I simply set a task as blocked vs creating a new Impediment work item?
My take on this is, Microsoft expect you to use an impediment for an item of work you would that is purely about unblocking a problem:
From MSDN:
By defining and managing impediment work items, your team can identify
and track problems that prevent it from completing tasks efficiently.
Teams typically identify impediments during daily scrums. The scrum
master is responsible for helping resolve these impediments and
improve team productivity.
For example:
"Alice needs a Copy of VS 2015 RC for the next spike, but IT won't let her install it", would be tracked via an impediment.
"Bob needs to get this Task code reviewed by Carol, but she's on leave today" would be done by blocking the task.
This is my take on what MS plan these to be used on. My experience, just pick what works for your team, adjusting in the retrospective where necessary. You could try using one or the other. So long as the work is done, blockers are unblocked and the team is happy, it doesn't really matter.
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.
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.