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
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
Our developers work from Sprint Boards, and they drag tasks into Closed stage. However, this leaves stories as New / Active when all tasks are done, and there is no easy way to know if story has all tasks completed
Is there a way to auto-close story when all tasks are done (without any additional plugins)?
Is there a way to identify what stories have all tasks closed/resolved?
Work items have independent states. Most of our experiences will not include automatic updates based on hierarchy. Either based on parent to update child or based on child to update parent.
You could refer Taylor's comment in this thread--User Story status closed but child Task still active?
Even though there is not any build-in solution, you could use some 3-rd party tool to auto change parent states: TFS Aggregator .
Another sample using Webhook to handle this. Detail solution here: https://twitter.com/danhellem/status/1173614918333030400?s=20
which leads to: https://github.com/microsoft/azure-boards-automate-state-transitions
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.
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.