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
Related
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.
Is there a way to set up custom alerts on TFS? I already use the web interface to create alerts, but I need to create custom ones that are not based on work item fields only, but also on the current and past iterations. I know that Power Tools used to have an Alert Explorer in previous versions of Visual Studio, but I don't know if it would have supported what I am trying to do.
Essentially, this is what I need:
An alert that notifies users of unfinished work items assigned to them when the current iteration (sprint in my case) ends.
I know some of you might be concerned about TFS not knowing what the current sprint is, but I have used this workaround http://intellitect.com/transitioning-between-sprintsiterations-with-tfs/ so I don't believe it's an issue.
I know I could simply query for unfinished items and move them to another iteration (sprint) in Excel, but we are trying to get into the habit of getting everyone to finish their work on time, and if not, as quickly as possible, and the notifications would go a long way in helping with that.
Would there even be a way to do this via the TFS API or through the TeamFoundation PowerShell modules? I have searched extensively but I can't seem to find an answer to this question. Any help even with a work-around solution would be appreciated.
If you are trying to get people into the habit of updating their work items then this will cause you more issue than it fixes. They are not doing it because they do not see the value.
However you could write a TfsJob that sends the emails. It would need to be Scheduled job that checks to see if there is outstanding work...
This should get you started: http://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspx
However what you have is a people problem that cant be solved by tooling.
what I like is getting a job thing, whether a SQL server one or a windows service, running, then manipulate workitems by myself.
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.
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.
We have the following scenario that we'd like to solve.
We create a new sprint, call it sprint "A" with a bunch of issues.
Then, we get a call from a customer which results in an emergency patch needing to be released.
Here, we'd like to create a new sprint for the patch, and move it to the top of the planning board. We're unable to do this.
I tried to create a second planning board in an attempt to solve this, but it seems like we cannot have two sprints going at once.
How should we handle this scenario of wanting to create a "patch" release cycle?
EDIT - Another thing I could do is run simultaneous sprints, but I don't know how to do it, and the post I found was not helpful at all.
Why not just add the new issue for the emergency patch to the existing sprint and rank it to the top so it will be done first? You could even configure an 'Emergency' swimlane to appear at the top of the board which guarantees that emergency issues would be shown with the highest priority.
If you really want to create a separate sprint for the Emergency fix you should enable Parallel Sprints (there's some information on this in the release notes, please ensure you're running GreenHopper 6.0.3 or above). Once you do this you'll be able to start another sprint on the same board as your existing running sprint.
Thanks,
Shaun