I am looking for guidance on process template switching.
Is this the best help page for change methology in an ongoing project?:
https://www.visualstudio.com/en-us/docs/work/process/manage-process
We are using the hosted (online) version of TFS, and would like to work WIP-limited and contiuous planning (Kanban) instead of time-boxed (Scrum), because we are a very small team and have rapidly changing requirements.
I guess this means we need to change our current process template from Scrum to Agile, correct? And that this not possible to do for an ongoing tfs project. You can start a new project but then you will loose all history.
But I have seen a help page showing that you can import new templates to an existing project, and that will make the same changes for you as starting a new project would have done.
Victor
This is quite broad, but I'll do my best...
We are using the hosted (online) version of TFS, and would like to
work WIP-limited and contiuous planning (Kanban) instead of time-boxed
(Scrum), because we are a very small team and have rapidly changing
requirements.
You've not outlined the process of how you work or what you need, but if you want to use a Kanban Process you should be able to use the "Board" under "WORK" and set WIP limits on columns using the "Configuration" options there:
You can then customise columns and WIP limits:
I guess this means we need to change our current process template from
Scrum to Agile, correct? And that this not possible to do for an
ongoing tfs project. You can start a new project but then you will
loose all history.
There's no need to change, see this post from Marin Hinshelwood where he says:
TL;DR – Select the Scrum template if you have an agile team and want
to reduce friction. Don’t create unnecessary friction for your move to
agility by selecting either the CMMI or Agile templates that suffer
from the legacy of the Microsoft Solution Framework (MSF).
This takes me back to the original question:
Is this the best help page for change methology in an ongoing
project?:
The answers is yes, BUT only if you need to make heavy customisations, start by changing the Kanban board in the "Board" view and only come back to the Process Template customisation if you need to make more changes. You can add / change Kanban columns instead of adding "states".
I want to manage a 3-tier Application Develpoment (Data/Business/Presentation) with scrum in jira but do not know if I use 3 Projects (one for each Layer) or one project and arrange the layers with the epic tag function.
I have found a lot about big scrum projects but not with this structure and the most articles refered to big teams that we do not have.
The problem with tools is that they will attempt to drive your adoption of scrum. I advise stepping away from the tool and considering how you see the approach when simply using scrum. Then see whether the tool will model that.
For the situation you describe, I would think about one product and one product backlog, with multiple product backlog items. The product backlog items would describe vertical slices of functionality that cross all three tiers of your business model
It is unusual when using the Scrum framework to break out the tiers of the application in to separate projects. With Scrum we typically work on user stories that represent vertical slices through an application that deliver some business value.
Separating out the tiers means that:
You create external dependencies, which makes it difficult for teams to resolve their own problems. The Scrum Guide includes the following: "Cross-functional teams have all the competencies needed to accomplish the work without depending on others not part of the team."
Measuring the rate of progress of 'done' software becomes more difficult. The Scrum Guide says: "Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available."
You create a synchronisation and resourcing problem in that the teams have to work at a balanced velocity so that they build the three tiers at a consistent rate. For example, the business tier development mustn't get too far ahead of the presentation tier.
Testing may be less effective as you have integration testing that spans several teams. This makes coordination more difficult and it may increase the time between when the code is written and when bugs are revealed.
My company uses TFS 2008 with the MSF for Agile process template. We are in the process of planning an upgrade for TFS 2010. We use Scenarios as a container for functional requirements with linked development tasks, bugs, etc.
In order to save the state of a Scenario as 'Resolved' or 'Closed', I would like to enforce that any development task or bug that is linked to the scenario is also closed. With TFS 2008, these are links, in TFS 2010 we plan to use child work items.
I have been reviewing the work item type definition schema and MSDN documentation, but nothing is jumping out at me as a solution to this problem.
Can it be done? Thanks in advance for any help!
What you want cannot be done directly. The saving of a work item is what is called a Notification (rather than a Decision). That means that you can only do TFS API stuff in an event after it is done. You cannot block it.
However, there are ways to get the "effect" of what you are looking for. If you modified your template so that your parent work item (I think you called it Scenario) had the State control (not the field) as read only that would make it so that only clients that don't use the normal Visual Studio controls can change that value. (This could be worked around by your users, but it would take some effort to break the rules).
But there is one more step. You need to get the parent work item to "Resolved" somehow. For this I recommend a open source tool that I wrote called TFS Aggregator. (Or if you plan to "roll your own" you could use the code there as a starting point.)
You can find TFS Aggregatoron codeplex here: http://tfsaggregator.codeplex.com/
It is a great tool for rolling up changes and totals to parent work items. You could put in a rule that when your child items are all "done" to move the Parent to "Resolved".
EDIT: I realize now from your question that you have more than one type of Work Item as a child of the parent Item. TFS Aggregator does not support that right now (but it may in the future). It was written to aggregate tasks to Bugs or PBIs. Still, it would probably be easier to modify the code of that project than to start from scratch.
I don't think this is possible "out of the box". I would recommend you write a query to find cases where the "rule" is violated and handle it that way.
If you MUST automate this - You could use the TFS Eventing Service which can invoke a Web Service.
Set it up for when a Task or Bug is closed - query the database for the Scenario and if all the Task/Bugs are closed - use the TFS API to advance the Status to Resolved or Closed. You could limit the allowed user to make advancement to the account the Service runs under.
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 6 years ago.
Improve this question
I recently shifted to a new organization that follow Agile mode of development. The current project we are working has stalled due to many requirement changes that were reported recently. Since this is my first Agile assignment (after working in 4 years in non-agile environ), its a bit hard to differentiate where the problem really is.
Ruby on Rails is the platform that is being used for development. Since I can't ask a vague question, I will narrow it to this.
In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)
Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?
In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)
It is OK (albeit not wise ;-)... so then an agile development team would tell them "fine guys, this would cost this amount of extra time and consequently this much schedule slippage."
If they are willing to pay the price, all's well.
If they decide that maybe the new feature is not that urgent after all, all is well too.
If they insist on including the new requirements and keeping the original schedule, that project is not agile :-(
Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?
I don't think the design should be ready to welcome any kind of changes and any new features - that would only lead to bloatware, and a lot of extra work which in the end proves useless.
Agile projects should have some sort of roadmap too, so that the developers have at least a rough idea where the product is supposed to be in a year's time etc. This would allow them to plan forward and extend the design to make room for probable future changes.
If business doesn't give timely information about the roadmap (or if it proves unreliable), that is (usually - barring really unforeseen market/environment changes) business' fault. If the team did not use that info wisely, it's their fault.
Agile doesn't mean you don't have requirements or specifications or you can be free and easy with them. The business leads need to know what they want. The benefits of being agile is that if you do need to change paths, you can do that in an easier way, so you can adapt quickly.
Requirements changing will be painful no matter what your development methodology. There still has to be a strong clear plan, at least at that point in time.
Agile projects are supposed to have requirements gathering, design, analysis, coding, testing; just like the waterfall development model. However, in an agile project, the phases are supposed to cover less ground and therefore, happen faster.
I agree with Péter Török's answer, but its also the responsibility of the agile team or the agile team manager to teach the business team that the project will deliver better results each round if they postpone new requirements until the next requirements phase. Since a round is supposed to be 30 - 90 days, most new requirements can wait. The few requirements that can't wait, need to have a time and schedule cost.
Opinion of a Scrum Master here. It sounds like the business is lacking a clear knowledge of what 'agile' is, or how they implement it. Agile needs to be applied with structure, whether that be Scrum or Kanban or something similar. Too often it is a synonym for 'we don't design or document' things.
If you are meaning a team using Scrum, this would be manageable as long as the Product Owner and Scrum Master are on top of their game.
If the business team are giving requirements 'at will' that do not align, it is up to the Product Owner to take these on board, and prioritise a list of tasks prior to sprint planning. If they don't align with what has already been done, they may be estimated as large stories, due to the need for refactoring etc. by the team. It will then be up to the Product Owner to decide if it is worth proceeding with them despite the size, or working on alternative stories that align with work already done.
This would be a tough environment for the whole Scrum team to work in, but you would expect the business to see the lost value by changing direction between sprints, and hopefully align the product to a direction before too long. It certainly is not the development teams fault for not anticipating this, I would more say the Scrum Master and Product Owner need to have some serious words with the business units involved.
There needs to be a buffer between the sprint and the backlog.
The Business Team own the backlog and the prioritisation of the stories in the backlog but once the Dev team have committed to x number of stories in the sprint then it is unwise for the business team to tinker with its content. If you find this happens I would suggest shortening the length of the sprints.
If however a super urgent new requirement comes up that just cannot wait for the next sprint then another story/stories of similar points value have to be removed.
It is important that the business team manage their backlog so that in the sprint planning meeting the next set of stories are fully specked, prioritised and ready to go.
In agile, is it ok for the business team to relax and give requirements at will?
Yes, it's ok to change requirements (maybe not relax), but in our teams we will not disrupt or change the scope of the sprint unless the work currently in scope of the sprint is made redundant as a result of the new requirements added to the product backlog by the product owner (not the sprint backlog). Also note that if you commit to 100 points worth of work in a sprint, you complete 80 points and the the requirements change enough for the sprint to be disrupted then the team has still delivered 80 points that sprint based on the POs original requirements. (important when dealing with external clients)
its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?
We have a very high-level understanding of the overall features/project being worked on, however before we accept User Stories (broken downs chunks of the feature/project) we ensure that we fully understand what the Product Owner wants. If the product owner is unsure then we will ask the person whom does know. Note I am not saying that you plan out the whole project, you only nail down 1 or 2 sprints worth of user stories.
(This is how I do it, but there is no prescriptive rules, every agile rule make Agile less Agile - My opinion)
No, it is not ok to give requirements at will.
There is a general notion that business and development work together on daily basis and do that not primary in written form, but as well face to face (often to review or plan stuff). The idea is not to make too much assumptions on the future, but some and go with these.
Having done this as a coder, the only advice I can give: Setup for change. As you learn about your framework, the product side learns about the business.
If you run into problems like these: Its actually important that you fix this problem. This is what you have sprints for: Fail at something and then fix it after a retro. Doing this for a while should lead to a sane organized process how to get all the requirements at the right moment.
However: Proper engineering has hurt no-one yet as well as proper security and requirements engineering. If you need to do this despite your agile process: so be it.
So far, I've been using TFS only as task management, but never as an time report nor ticketing system. I've been using third party software for each. I want to use more out of TFS if possible to include these reports too.
Is TFS able to handle ticketing system good?
And what about time reports?
What templates can I use for these reports?
Is it be ok to give customer access to TFS to add bug reports?
First of all, any of the work items can be customized. Secondly, in many cases, someone probably has done so already.
I would think it would be good for this. Consider that it already has the ability to have a bug filed against software; have it assigned to a developer; and to record when it's fixed. The Bug work item already keeps track of time (if you fill that in).
I'm not certain about allowing customers in. I suggest you look in to the Web Access for that. You might have to maintain actual Domain accounts for the customers.
Our TFS is one mother-ship where we have our source repository, do our automatic builds/CI, manage our Product and Sprint backlog items (dev task items), and manage bugs - like you would using any full scale bug tracking system like bugzilla or jira (if that is what you meant by a 'ticketing system' - if by ticketing system you meant something like BMC Remedy, then its a different ballgame).
Our firm follows agile methodology and we use Conchango Templates which in my opinion is great for agile shops. Its highly customizable and is easy to learn/follow. As far as reports are concerned, these templates generate reports per day, per project, per team, per person by month, year and all that jazz... depends on what you really want.
Regarding giving customers access, it totally depends on your and your network admins comfort level.
Hope this helps...