Where can I find a practical example on how to use Bug, Risk, Scenario, Task and Quality of Service Requirement work items?
On MSDN documentation I found this topic: http://msdn.microsoft.com/en-us/library/bb668962.aspx but it is not enough for me to deeply understand when to use one or the other.
Thanks!
I don't think there is a single prescriptive way of using the work items. You have to adjust this to your own process and your own needs and primarily decide what you want to get out of TFS a this particular process template.
A good place to start might be the literature on agile methodology, for example:
User Stories Applied: For Agile Software Development
Succeeding with Agile: Software Development Using Scrum
Related
I am currently using Scrum for my TFS project template and I really want to start using some of the product planning, project management, and bug backlog features that Agile and CMMI offer.
I have found a lot of documentation based on the differences between Agile and CMMI through these links:
Link 1: Stackoverflow Question
Link 2: Social Microsoft Question
Link 3: Official Documentation
Link 4: Similar Official Documentation
I have not found anything that can represent real drawbacks to either of these approaches. These are some of the questions regarding downsides that I have been thinking about:
Would one template be more effective at one particular aspect than another?
Are there any performance issues that would make one template better than another?
Is there a learning curve in implementing either one of these templates?
Would using a process template like CMMI for a smaller team overall hurt productivity than something simpler like Agile?
These questions are not concrete, meaning I am not specifically looking for answers to these questions. If there are no significant drawbacks to using Agile or CMMI, then I will simply choose a process template based on preference of the features offered.
Requirements:
I am working with a small team (5 or 6 people) for a large company that follows regulated procedures to submit changes and would like to have easy navigation to specific work items based on sub-areas.
Yes this sounds like we should go for CMMI, but for a small dev team, I am not sure if this template would beneficial as far as time spent on developing the template than to just simply use Agile.
I would suggest that you seriously consider wither either of the MSF templates are for you. I would suggest that unless you are Microsoft Consulting Services or you are not doing agile then you should be on the Scrum template (forget the name its about the practices that are supported).
http://nakedalm.com/agile-vs-scrum-process-templates-team-foundation-server/
There is, in my opinion, no reason to ever use one of the MSF templates.
I work in a remote company where email, forums and IM are key communication tools. We don't formally follow any book-methodology but have been evolving towards a more agile-style setup in terms of release schedules, client interaction and a sort of scrum adapted for distributed teams.
We use Jira on one project and I wondered if Greenhopper might be of use. Or, whether it is focused on teams who adhere much more formally to the entire Agile dogma, and would end up getting in the way?
I don't want to get into a discussion on if Agile is good or bad, what it involves, etc... just whether Greenhopper is useful to projects whose methodology is inspired by Agile principles rather than defined by them.
GreenHopper is pretty flexible. I've seen marketing teams, operations teams plus more using the task board to track their work in progress without any real though to 'agile'. Give it a shot and let me know how you get on.
Thanks,
Nicholas Muldoon
GreenHopper Product Manager
I won't comment on Greenhopper, since I don't have recent experience regarding it.
Many tools are designed based on a "pure agile" model. That is, for a single team, working on a single thing for or a single product owner.
However, in my experience the vast majority of real-world organizations – even the very small – have a more complex landscape they need to manage. Often, even a single freelance developer has a load of things to work on: the active project(s), leads for new projects, maintenance of old projects, and so on. And simple tools that have a pure-scrum-one-team-works-on-a-single-thing-at-a-time just won’t cut it…
Agilefant is IMHO, while complient with "the agile dogma", also pretty flexible with respect to how people can be assigned to multiple things. Also, it's quite flexible in terms how different types of work can be modeled into it (that is, there's no need to conduct every project as Sprints, and so on).
DISCLAIMER: I'm Agilefant's product owner.
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 5 years ago.
Improve this question
How significant are the differences between
Visual Studio Scrum 1.0 & MSF for Agile Software Development v5.0 process templates?
Has anyone used one over the other?
We are currently using external tools (TRAC) for implementing Scrum in our development process, since MS came up with additional process guidance in TFS2010, these 2 things confuse me to the core!
Unsure, which one to adopt!
You're not alone! We have used both, mistakenly starting with the MSF Agile 5.0 template. If you are using Scrum specifically, I would use the Scrum 1.0 template. The Scrum 1.0 template was created with Ken Schwaber, one of the founders of Scrum.
The MSF Agile 5.0 Template contains workbooks which allow a lot of control over reporting data using excel. But, there's many more disadvantages. It doesn't have a release burndown report. In order to produce a usable sprint burndown, you need to record actuals in your tasks. The product backlog is hard to keep groomed. The user story is the only backlog item, so tracking engineering spikes or non functional requirements are awkward.
The Sprint 1.0 uses a "Sprint" workitem type which makes velocity and burndowns a snap.
So, as far as tools go, it's pretty good.
My background summary: TFS Architect/Admin from 2005 to present. Many large and small development organizations from 20 to 7,000. Public and Private sector. HIPAA, FDA, SOX compliance. ALM, SCM, RM.
The answers currently provided are attempting to answer the question from a project level perspective, which is typical, rather than from an organizational and maintenance perspective. And also siding with one camp or another, which should be avoided.
The answer to your question depends on your situation. What type of queries or reports are needed or would like to be seen in the project? And to reiterate what the top response is: the tool should not dictate scrum and to go along with that, does the project need to be somewhat flexible?
A take away from real world scenarios that I have experienced with multiple clients, is that they usually start with the basic Microsoft Visual Studio Scrum 1.0 template and then add things to it. ie: queries, reports, work items, dashboards, etc. Which inevitably leads them back to either the Agile or CMMI template with the burn down reports/queries/work items being added. Have seen this multiple times regardless of the size of organization.
It wouldn't matter if the god of scrum came down and created the scrum template for TFS. A more important question is 'What does your process support; how disciplined are personnel to follow process; and can they agree on semantics? If it's a real bother that the names don't match up, the work item types/names can be changed/added/removed, it's still the process driving it all that matters.
One real important aspect of the templates, from a pure TFS perpsective, is that scrum 1.0 work items may be added to the the agile 5.0 work items easier than the other way around. Why? The fields and data entry points already exist in agile where they do not in scrum. Which in turn reduces the amount of time figuring out which fields that exist in the system to reuse without causing conflicts.
Without sounding factious, and I'm trying not too, it's similar to stating that using Microsoft Word is to confusing to people because there's too many features/functions. Most people ignore these features/functions until there is curiosity or need to use them. Otherwise companies should not have the added expense of paying for Microsoft Word licenses and just use WordPad. Curiosity and need is what promotes understanding and knowledge.
SCRUM template follows some of SCRUM terminology and artefacts. You have sprints instead of iterations, you have user stories instead of requirements, tasks, burndown charts etc. But in my opinion TFS is hard to use because it is not very productive.
We are using similar non MS template for Visual Studio TFS 2008. During my first SCRUM project we used directly TFS and Excel to collect user stories, to prepare tasks etc. It was extremely slow. Just creating tasks for 4-5 developers and 4 weeks sprint (I will never use such long sprint again) took me always about two days. Such a waste. Moreover there was no build in support for printing cards for taskboard. Another disadvantages of non MS template (not sure if this is the same for MS one) is that each reported bug is immediately added to product backlog (it is new user story), there is no way to collect constraints, user stories don't have predefined field for acceptance criteria and tasks don't have field for real time spent on task completion (good for retrospective of estimates). Fields can be probably added if you have TFS under your control but it is not my case.
I still have to use TFS (company policy) but I'm working with user stories and task as much as possible outside the TFS - pen and paper works best. Still TFS is good for tracking sprint progress and automatically generated burndown charts but you have to find good balance between number of tasks, complexity of tasks and sprint length.
This MSDN page might be of use: Choose a Process Template.
It does a decent job at highlighting the differences between the following 3 default process templates.
Scrum Process Template for Visual Studio ALM
MSF for Agile Software Development v6.0
MSF for CMMI Process Improvement v6.0
Keep in mind that it's aimed at the Visual Studio 2012 suite of tools.
The Visual Studio Scrum 1.0 template was build from the ground up to support Scrum, using Scrum terminology as much as possible. It is being developed in coordination with Scrum.org and the Scrum Professional Developer program. If you are using Scrum, the VSS 1.0 template will offer you less friction than the Agile template.
That said, you should be scrummy and question if adopting TFS and the VSS 1.0 template could provide you better value than using the current tool you are using now. Questions to ask here are: will you gain benefit from the integration of Product Backlog Items, Sprint Tasks, Code Checkins, CI builds, Manual Tests, Coded Tests, Unit Test Results, etc.
Perhaps some of the standard reports allow you to gain a better insight in the Quality of the Product Increment. E.g. Are you Done? Unit Tests & Code Coverage reports, Test Reports, Build Reports. Do these help in answering that question better?
Perhaps none of this is applicable and using your current solution is the best way for your team to improve. Its up to you to experiment and decide.
(Or you can hire me, and I'll gladly help you decide after having worked in the team and finding out what issues could possibly improve your team ;-)
I finally was able to complete the installation of TFS and started the creation of my first team project which introduced me to the process template.
After following to the link to Microsoft's site for process template information I was inundated with new information to consider. What templates have all of you had experience with that either worked out very well for you or were more of a stumbling block to the project? What were the biggest advantages and disadvantages you've encountered?
Some information about my project, I'm the lead developer for a small company and will be using TFS/VSTS to create an intranet portal to consolidate the end users day to day and increase automation to enhance productivity etc. It's entirely new development taking advantage of C#, ASP.NET and SQL Server 2008.
Ideally I'd like to take advantage of features to enhance collaboration with the stake holders to help add desired features and to track the status of development and offer feedback etc. I was also looking to take advantage of JetBrain's TeamCity for my TFS so if any specific template / software really adds cohesion between TFS, TeamCity, Developers, and Stakeholders that would be ideally what I'm interested in.
Are you already using a software development process like scrum? If yes you can try this Team Process Template over here.
How large is your project team and the project? Microsoft has published one of it's internal Process Templates (MPT) over here. You can get some guidiance and inspiration from this template.
As tangurena mentioned. People use the standard templates, change the bug a bit and store some documents there. I would recommend to keep the process 'light' as well.
However the process template isn't all.
Here are some ideas what I would do (in your case):
Create some high order workitems (features/stories) which stakeholdes can create (constraints and TFS user groups are your friend). They can then access their requested features via the TFS Work Item Web Access. That way you don't need a CAL for them
Create some reports which show planned work accodring to releases.
Setup the build automation and create Reports (a.k.a. Release Notes) from your workitems according to the builds.
What were the biggest advantages and disadvantages you've encountered?
Imho the biggest disadvantage is that you start believing that the template is your silver bullet. It's not, it's your starting point.
The TFS ecosystem offers you alot opportunities to create own bits of software that fit your needs. Just check out the TFS API.
Here is another nice agile-based template (original is on SSW, but you have to get around a login wall).
This template helps enhance cohesion between developers, managers, and other stakeholders by including more robust support for project process (documentation, reviews, &c., &c.). For example, there are types built in for process elements like release plans.
In general terms, I'd favour as small a process as you can manage. The more states, the more fields you have, the more likely the information in them is just plain wrong.
We're running with our own version on the Agile template. Most of what we did to it was delete stuff.
You can use the TFS API to log builds into the database, which should enable you to bridge TeamCity and TFS. Other than that, I'd probably just go with the web interface that comes with TFS, I don't think you need third party software for this.
K.I.S.S.! I created a custom work item based off the Agile one. And thats it, just one work item. There is a "System Severity" that IT uses and a "Business Priority" that the client/customer uses. There is also a "Request Type". With those three along with the built in Area and Iteration the entire team, including the clients can query the work items to get only the items they care about for the release they are concerned with (or all of them regardless of the release).
I did not modify the state machine much at all. This left us with something that is very flexible for everyone. Everything from blue sky requests to the mundane content/visual bugs can be logged there.
The client uses TFS Web Access (unlimited CAL) and the devs (me and 1 other) use VS. At my last job I created the same setup, the dev team was a team of 5 and it worked even better there! I was dev lead there as well and technical PM.
The biggest advantage was having a very flexible system for everyone, when using 1 work item type for everything. The disadvantage would be a learning curve for the client, but once they knew how to use it most like it. A suggestion would be to look into cheaper tools out there for a similar implementation, but, our .edu discount with MS cant be beat.
I would have to say that you must identify the system you will use for your company's SDLC first. The process template is merely a tool and without a good understanding of the underlying process it will not help and can make things more difficult. User adoption is crucial to the success of the SDLC and process template.
We use Scrum for Team System. We chose this due to our experience with Scrum as an SDLC methodology. There are several excellent books and articles on the web to help you get up to speed. Scrum will tie together the business stakeholders into the process.
In our system the Product Manager is in total charge of Product Backlog Items and works with myself and the CTO to prioritize them into Sprint Backlog Items.
The only change we have made to the process template was to add a "Failed Test" state and corresponding workflow.
It might not be the best template for you but I still wanted to mention it here: XP for Team System. It is basically a simplified version of MSF for Agile Software Development:
[...] it removes some of the setup tasks that an XP project will probably not want to undertake and changes the Work Item Type name Scenario to Story.
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 5 years ago.
Improve this question
We've had several sprints with the traditional whiteboard and PostIt notes and are ready to move forward to integrating the process into our Team System environment. One tool we're considering is Conchango's "Scrum for Team System" (http://www.scrumforteamsystem.com/en/)
Has anyone tried this tool in a real world scrum process? Was your experience positive or negative? Is the tool worth the licensing fee in your opinion?
We use Scrum For Team System and love it. It really does a good job of merging the TFS and Scrum processes.
We also got the task board (the part you have to pay for) and really like that too.
Even with Scrum for Team System, TFS via visual studio is not good for planning meetings (though it is ok for standups) The task board helps a lot in visualizing the work remaining and in moving it around.
Before we got the Task Board, we would use post it notes for our planning meetings and then enter them in to TFS after. And even though the Task Board is nice, if you don't have at least 2 people working on it in a planning meeting then it is not enough. We have 3 laptops going for a team of 5 + 1 (scrum master) and that works great. If you don't have that then I would still think about doing post it notes.
The task board allows you to refresh and see what the other are entering in. We have one computer hooked up to a projector so that the others can see what is happening. We all then brainstorm like we would on post it notes, but the people on laptops enter the data into TFS.
For us, it works great!
Later Note: If you do choose the Scrum For Team System template then I STRONGLY recommend that you read the Process Guidance. We had to figure out a few thing the hard way before we sat down and read it. Especially on how to handle defects (i.e. when is it a Bug and when it is a Sprint Back Log Item that goes back to "In Progress")
The templates are free. It is only the Task Board Application that cost a modest fee. You can use the templates without the Task Board although I highly recommend using it as wll. I think the biggest advantage for my team has been that the ScrumForTeamSystem tempaltes integrate into VS and provide a seamless feel with the rest of the development environment.
We love the ability to attach the PBI's to check-ins and have them show up on the Daily Build report.
If you are are missing something you need, you can fire up the VS template editortweak the templates to your liking. For us, we added a "Requested By" field and a "Testing Status" field to the PBI template.
The 2 shortcommings that annoyed us were that the "State" of the PBI's were not the same as SBI's (No Ready For Test on the PBI). We do testing/validation at the feature level and not the task level and wanted to track the PBIs status so we had to add our own custom field. The second issue was that there is no report out-of-the-box for a PBI burndown/up at the Sprint level. So you can't see how you are doing at delivering stories, only tasks. You have to make your own.
We don't really use the "Bug" template much (we ship flawless code:) ). No really, there is no such thing as a bug against work in a sprint; so the only time we record a bug is if a client finds an issue in the production code where it didn't work as advertised.
As Vaccano said, it isn't nearly as fast as a whiteboard or post-its in a meeting environment but if you get a couple people really good at using the tool and a couple of laptops you can make it work.
I evaluated several products and the simplicity and price of ScrumForTeamSystem can't be beat.
Like others have said, beware that the Conchango template handles bugs very differently. The idea that unreleased Backlog Items are bug-free is not just a suggestion; there is literally no way to track bugs affecting the current sprint's work. I found that this disadvantage outweighed the advantages.
If you are searching for an online Whiteboard you can have a look at the Scrum tool Agilo. It was build especially for distributed teams which do not have the chance to work on a "real" whiteboard.
For a quick information you can have a look at this video.
The 3.0 version of the template for VS 2010 changes how the tool models Scrum in ways to very effectively support multi-team projects and the typical interactions one will find in larger projects.
Regardless of version, it is currently my default answer for Scrum projects in Microsoft environments. As mentioned, the task board and the (new) ScrumMaster's workbench are incredibly valuable as well!
We build Urban Turtle that extend the Microsoft ALM platform with an intuitive Web interface and simplify your agile project management. By providing a Task Board and a planning board directly in web access you don't have to synchronize anything. The installation is a simple process. 2 minutes to install on the web access server. Nothing to setup on the client desktop.
Don't take my word for cash have a look at what Brian Harry from Microsoft said about the product :
http://blogs.msdn.com/b/bharry/archive/2010/10/21/urban-turtle-3-5-released.aspx
Have a look at the website and send me your feedback
urbanturtle.com
Dominic Danis
Product Owner.