I am trying to find a way that will cause TFS to automatically create a second task when another task has been completed. The idea here is that once a developer has completed a task and moved it to the done column a 2nd task is created off the first one for the QA/QC members to start looking at the code and doing what they need to do.
Any suggestions?
There is no built-in feature, but there are tools, many open source, that can help you implement your request.
One is TFS Aggregator: I am part of the core team, always looking for new contributors.
This should be managed via your user stories, either via having a task for testing that can be grabbed by the QA team once the user story is ready for QA, or by defining a board column for the user story to indicate that it's development-complete and ready for QA.
Once a user story starts development, you shouldn't be adding tasks to it. Each task should be defined and estimated prior to the sprint starting for capacity planning purposes.
Related
We use Jira for issues bugs estimates and timesheets.
I've seen 2 approaches to using Jira and I want to hear what other people are doing.
Approach 1:
Log one feature, such as "Allow user to save as CSV". The task is assigned to a Developer and the workflow progresses from Not started, In Progress, Complete. Once done it's assigned to a Tester and they change workflow to Testing, then to Tested/Completed.
Approach 2:
Log a task/user story called "Allow user to save as CSV". Then developer logs subtasks such as, Front end, Backend and tester logs tasks such as create test plan, test right clicking. Once all dev and test sub-tasks are complete, someone marks the task as completed.
I prefer the first way, I've heard the second way is better for tracking time. It seems harder to manage what's going on with a sea of issues in Jira.
My company does first approach. This seems to be working so far ( about a year now ). With either approach I really love how everything seems to be logged in JIRA for history tracking.
I recommend using sub-tasks when you need to have work proceed in parallel. Or if the parent task is really large and the sub-tasks are around a few days each. But don't create sub-tasks unless they are needed.
currently we are having the following states/columns in JIRA:
Open/Todo (-> Developer takes task and starts work)
In Progress (-> Developer sets tasks to done)
Done (-> QA tests on staging and sets task to ready to deploy or reopens)
Ready to deploy (-> Developer deploy these tasks at date of release)
Deployed (-> QA/Stakeholder tests task again on Live/Production and closes or reopens)
Done/Closed
In my current understanding this is wrong, because we try to handle two concerns in one status dimension: Development and deployment. I would like to decouple sprint from release/versions. Currently we cant end a sprint until all tickets are approved on production which leads to bottlenecks.
What would be your suggestion? One idea I have in mind: Limit the status to Open, In Progress, Done, Closed and handle the deployment/release over JIRA build-in versioning. If a problem occures on production, a bug ticket must be opened.
Otherwise I don't see a chance since the versioning/releasing of JIRA 6.4 does not seem to include status columns by itself.
Is releasing to production part of your team's 'definition of done'? If it is then the workflow you have makes a lot sense.
There is no separation of concerns between development and deployment. Code that has been developed but not deployed has no value to the business. Development is simply a step in the process towards release, which is the point at which value is realised.
A sprint is a timebox, not a set amount of work. When the timebox ends then the work that you have still in progress is not 'done'. If you are regularly unable to complete all the work you bring in to a sprint then that suggests you are bringing too much work in. The team's velocity, which is a measure of the work that gets 'done' each sprint, should be a good indication of what your sprint capacity is.
If your bottleneck is the release to production and verification of the release, then perhaps you should focus some effort on improving this process? Possibly this could mean more release automation or better coordination with the stakeholders over validating releases.
I have started using TFS Integration Tools to migrate work items from one TFS2010 project to another team project within the same collection. After some small trial runs and modifications to the field and value mappings I started a migration on our entire product backlog. Approximately 170000 change groups were discovered and analyse started. However, during the analysis the connection to the TFS server was lost so the migration had to be restarted. After the restart approx 340000 change groups were identified (roughly double) without any significant changes being made to work items in the backlog.
Has anyone experienced a similar problem or are aware of settings or changes that can be made in the tool to limit this increase in change groups? The amount of time taken to analyse so many groups is causing the migration to take much longer that was initially expected.
After several runs, I found out that the count appears to be a running total so logically enough when I experienced a break in connection all change groups had to be re-analysed causing the "doubling" in change groups.
I am reviewing JIRA for possible use within several development teams at the company I work for. We use Scrum as a base for our project management. We have good, self-organizing teams, almost no assigned work, etc. JIRA seems great for some of these items, but something we are struggling with is handling the management of process vs technical tasks and something we call "issue bundling".
Process control. Currently we will create a story, say "The graph on the Profit and Loss report has issues with overlapping legend text". Okay, good enough. We will then create a technical sub-task, for simplicity let's say it's "Research and correct the issue". Next we have a set of process sub-tasks that we create. Peer Review, Make Build, QA Testing, Merge, Track. Each of these can then be independently assigned to users and placed into the Pending bin on our scrum board (BTW, we use a Pending, Awaiting Action, In Progress, Done, Merged model rather than a todo, in progress, done model). Pending basically means, I'm waiting if I'm next in priority. During development the programmers will grab the technical task, set themselves as assignee and move to in progress. When they are done they will move it to the Done bin and then update the Peer Review process sub task to "Awaiting Action", and set the assignee to their code partner. Emails are sent, peer review is done. When that is completed the peer review partner will move Peer Review to the Done bin and set the Make Build sub task to the build manager and move it to Awaiting Action. Build manager sees this, makes build, moves it to done and updates the QA Testing ticket to a Awaiting Action status, you get the point.
It's working, but are their any suggestions on alternatives, best practices, etc. Is creating technical and process sub-tasks not the way to go? One thing I notice is that we have to filter the issue list to hide the sub tasks and the scrum board can get pretty overwhelming for the stakeholder who just wants to see the status of the parent story. Since the parent story does not move until the sub-tasks move they don't see anything that is of interest to them, not even if the story is "in progress" while the sub-tasks are moving. Ugh.
Issue bundling. We often have a set of issues that are related perhaps tightly, but typically more general. For example, all issues that are related to reports in our software. At the present there are say 15 known issues. These issues may be on different reports in the system, with specific steps to reproduce, etc. When we are gearing up for a sprint we will select bundles of these related issues. The reason is that QA can more efficiently test a bunch of small fixes that are generally related in one pass rather than testing each report as a separate process.
Currently we move each issue to a subtask of a bundle. The bundle for example might be simply called "Report Fixes 1", and it will have, for example, 5 sub-tasks that are technical, each being a different report bug to be fixed. We can then add the process control items from above to the overall bundle. We also know that we won't merge until all items in the bundle are done, so they all get the same version.
However, as stated above, visibility is reduced as you cannot see the status easily of the subtasks now that they are in the bundle.
Again, best practice? Ideas? How are others handling this?
Brian,
Have you considered combining your process sub-tasks (Peer Review, Make Build) and your Scrum board "bins" (Pending, Awaiting Action)? Subtasks are the usual way to provide parallel tasks in JIRA, but the way you describe the whole process it sounded more linear. If each story really gets bounced from one assignee to another, just change the assignee and the status.
"Issue bundling" sounds like Epics in GreenHopper to me. You can also do a similar thing using a Labels field (standard or custom) to group issues.
~Matt
Here is how we are handling this -
The process sub-tasks you mentioned are statuses in our implementation. So, I'll have the story broken into Technical tasks that the dev finishes and then moves the story to "Pending Review" status, from where it goes to Make Build and QA Testing and so on. This is pretty much what Matt said as well. This workflow gives the stakeholders the sense of the progress that is being made on the sprint and thus is very helpful.
As such there is nothing like best practice in JIRA, it is very flexible and one can use it the way one wants/needs.
I agree with you on Epics not being a complete solution. We overcome this by adding labels and creating filters and swimlanes based on these filters.
Our company has a small development team in-house but we mostly outsource our customer projects to external consulting firms which we don't manage directly. We only interact with their project manager and maybe a team lead.
I'm implementing TFS 2010 and Scrum for our internal team for Project Management, Version Control and Sharepoint shared documents access.
My problem is how to to manage the external teams.
They won't use our TFS for Version control and I can't forced them to use Scrum and report as such (report on a task level adding remaining hours).
The solution I came with is this:
Use the “MSF for Agile Software Development v5.0” template in Team Foundation Server.
Break the project into user stories and then create a task for each.
The tasks have these fields:
Original Estimate
Since we’ll track percentage of completion, this will always be 100.
Remaining
This is the percentage of remaining work.
Completed
This is the percentage of competed work.
Their team lead will update the remaining work in percentage for each user story (on the task level).
If progress is reported correctly I can print a "Stories Overview" report periodically and see the percentage complete for each user story,
I'm sure it must be a better way out there and I'll appreciate any help on getting to the right direction.
Thanks
We are basically doing the same thing ... I have 10 in-house developers and teams around the world working on their projects. Most of the work we do overlaps between external and external. We are using TFS2010. We break a piece of development into user stories into lots of tasks and eventually bugs. We view the status of the external projects by looking at the breakdown of work on the individual work items.
Part of the development process flow is to get the code into TFS source control; and the control of the logs changes as it comes back into our system.
The external PM's then use the web interface spreadsheet upload update the data on these logs (Including the time spent / work remaining) so we can see the state of the work. You don't need code upload to set a work item to test / complete.
The process flow we have on the external work is; on a given user story item you can then see the state of development for all those tasks.
List item
To Spec
Specified
Spec Agreed
Open For Work
WIP
Development Complete
External Test
Source ADded to TFS
Delivered to Internal Test
Internal Test
Complete