Choosing a Process Template for your Team Project

Over the years I have had many discussions about Agile vs Scrum process templates with both TFS and VSTS and migrated many Team Projects from Agile or CMMI templates to the Scrum Template.

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).

When you create a new Team Project in VSTS or TFS you are asked which Process Template that you want to use. This is a decision that you need to make at the time you create your Team Project and you cant change it later. You want to choose the template that is closest to what you are actually doing, or more accurately what you want to be doing.

Many teams and organisations make very good and seemingly rational arguments for choosing either the Agile or CMMI templates, however I feel that if you are trying to achieve any type of agile implementation for your team then this is the wrong choice. There are two key frictions that I think affect your choice:

  • Current Friction – If you have a discrepancy between what you are doing now, and the process template you choose then you will have a harder time getting folks to work within the bounded environment that you are trying to create. However you may want some friction if folks are currently doing the wrong thing.
  • Future Friction – As your process implementation moves to match your strategic direction, and the template lags behind , then you will have a significant friction for folks who really want to do the old thing.

Having the right rules to follow is valuable for figuring out the right path:

  • Create a Template for the Process that you want, not the process that you have.
  • Make it easy to do the right thing, and hard to do the wrong thing.

Making the wrong choice can cripple your teams ability to inspect and adapt by making their biggest problem trying to avoid the friction that your choice in template has created. While I also believe that any  team following any process could, with significant discipline, use any template,  if your team is an agile one then both the Agile and CMMI templates will create significant friction. Let me explain; there are three templates available out of the box:

  • CMMI – This was called “MSF for CMMI Process Improvement” and was primarily focused on those teams that need to monitor change and are following CMMI.
  • Agile – Formally known as “MSF for Agile Software Development” and is designed to support Agile development for teams that don’t want to be restricted by Scrum
  • Scrum – Also know as “Microsoft Visual Studio Scrum” was designed to allow Scrum teams a more familiar with Scrum.

However every single one of these templates supports both “agile” and “CMMI”, however only one embodies agility and minimises prescription and constraints, and its not the “Agile” template.

Why you should not select the Agile template

I have had a number of… arguments discussions with the folks that own “MSDN: Work with team project artefacts, choose a process template” about its inaccuracies and false choices and some changes have been made. However I have issue with one particular statement in there:

The Agile template is designed to support Agile development for teams that don’t want to be restricted by Scrum.

Lets forget for a moment about Scrum and look singly at the contents and expected use of the templates. I completely disagree that the “Agile” template is suitable for agile teams and I vehemently disagree that the Scrum template is restrictive. I believe that the opposite is true.

I believe that the “Agile” template (as well as the “CMMI” template) is in fact not agile and enshrines many common anti-patterns for agile teams. Its not really a surprise as the “Agile” template was not designed by agilest for agile teams. The “Agile” template is properly called the “MSF for Agile Software Development” template and the MSF part is important.

Microsoft Solution Framework (MSF) was designed by Microsoft Consulting Services (MCS) to help them deliver software to customers when consulting. The MSF for Agile template was originally an attempt to implement that non-agile methodology (don’t let the word Framework fool you) in a more agile manor and it failed (oh it gave managers a false sense of agile; vanity agile. Lets call things agile and do the same old thing we have always done.)

There are main issues with the Agile template:

  • Bugs are not on the backlog – As any good consulting team (sarcasm) knows you must hide your bugs from the customer and this template promotes that bugs are triaged separately to Stories. Yes you can change this to add bugs to the backlog, however the expected happy path is that you triage your bugs separately. From TFS 2015+ we can choose how bugs are handled on the UI.
  • Resolved (Code Complete and Unit Tests passes) – Yes I know that many teams still like to create a wall between Code and Test but to enshrine it in the template forces all teams to follow that line. Making this the path of least friction encourages users to do the wrong thing. You really cant be agile and throw bugs or features over the wall to Test.

In addition to the main issues there are a great number of paper cuts as well. While individually small they add up to significant friction:

  • Story Points – Why are people encouraged to only use Story Point? Are they the right practice for everyone, on every software? No, Story Points are just a complimentary practice that can be applied to any process. While I am a supporter of Story Points and I encourage teams that I work with to use them they are by no means the only method of estimating in agile. This should have a more generic name, like maybe Effort that allows the team, or organisation, to collectively decide how they are going to do estimation.
  • User Story – Is the only way to write backlog items to do so as User Stories? What about Use Cases? Should you struggle to write even constraints or non-functional requirements as User Stories? No, again User Stories are merely another complimentary practice. While user stories are an effective tool to help you decompose your work they are by no means the be all and end all. Having the Requirement type called User Story makes folks feel that every one should have a “As a | I want | so that” which is just not the case in any of the agile processes. Would it not be better to have a more generic term, a base class if you will, from which you can form any sort of definition of our work?

Forcing people into using these complimentary practices is silly and creates that friction. These practices are not required to be successful at agile however being able to break walls between departments and triage bugs with the rest of our backlog I would argue is. Don’t get me wrong, I like practices like Story Points and User Stories and they are right for some teams, although not all.

If you really want to be able to “let the team decide” on the practices that suit their circumstance, experience, technology and choice then you need to stay away from MSF templates entirely.

So what is the answer? What if I am not doing Scrum, but there are only two other choices, both of them MSF based. Well I would recommend that you use the Scrum Template anyway, and create your own agile process with this as the foundation. For folks that really want to have the Agile template, because they hate the word Scrum and anything associated with it. I kind of lie. I download the Scrum Process Template from TFS and change the same to “Agile for Company X” then reload it.

Why you should use the Scrum Template

Rather like the Scrum Framework itself the Scrum template was designed to be as light as possible while still embodying the common lexicon of Agile. Wither you like Scrum or not, it is an implementation of Agile and uses the same terminology. The thing that differentiates Scrum from other agile implementations is the Sprint and the Sprint is not really part of the Scrum template. You can easily change the Iterations to be any flavour you like.

Bugs are on the backlog, one state for the team working on something, no push to a particular practice.  Almost universally the terminology and workflow of the Scrum framework is understood by teams doing any flavour of agile. And if you have a team that needs a little legacy love you can easily add a column to the Kanban boards without enshrining dysfunctions in the template.

I always recommend that folks start with the Visual Studio Scrum template as a base and customise from there. There are a few customising that I like to see teams make if they need them, especially to help adoption:

  • Completed & Original Estimate – The Scrum template only has Remaining Work on a Task as this is the only metric that Scrum requires. However there are many teams that gain value through other metrics and the Scrum Guide does not say anything about not using them. I often add these two fields to the Scrum template for teams, and I never feel bad about it.
  • Requirement Type Field – Often organisations like to differentiate between Functional , Technical, or Regulatory PBI’s and this is another field to add. Making sure of course that it becomes a dimension in the Cube. Luckily the out-of-the-box template from TFS 2015+ has this field already, just put the values that you need.
  • Team Field Mode – Often the case for long term users of TFS is that they already have made good use of the Area Path field. Now they need to use it for team? Well, no. Create a Team drop down and with a little out-of-box wiring you remove the relationship between Team and Area Path. This feature is currently unavailable in VSTS and the product team are looking to make it unnecessary.

These customisations are non-intrusive and have a limited impact on reporting and upgradability. I spend a lot of time at customers migrating them from the Agile and CMMI templates to the Scrum template and while it is not that hard to do it does take time and money.

Conclusion

Choose the Microsoft Visual Studio Scrum process template if you don’t want to be limited by MSF. What other customisations do you make to your Scrum template to support your lean-agile process?

  • Pingback: Agile vs Scrum Process Templates in Team Foundation Server | ALMGuru: Visual Studio, Team Foundation and beyond()

  • Dusan Musak

    Thanks for an article, it was really interesting reading for me. I agree with your recommendation at the end of your article, especially with the first point about Completed & Original estimate fields. It’s really helpful when you have a possibility to compare your original estimate with reality, it help you to improve your estimation a lot.

    • Except that comparing your original estimate with ‘reality’ rarely provides any value 🙂

  • Pingback: Agile vs Scrum Process Templates in Team Founda...()

  • Daniel Tobler

    I had to convince customers shifting from Agile to Scrum template in many occasions already (despite they were not running Scrum). This article summarizes my reasons perfectly. Thanks for the blog. I will refer to it in future.

  • Nice article Martin!
    Additionally what bothers me is the possibility to play with the Velocity Forecast in the “Product Backlog” of the VS Online Portal. This is a clear misuse of the Velocity

    • What do you mean? The Velocity is not forecast by the tool but by the Product Owner.

      • I mean the possibility that the Product Owner can “play” with the Velocity number and see how it affects the Work per Sprint plan for the future.

        • But Peter, Velocity is not a constant. Many PO’s, as per the Scrum.org guidance in both the PSM and PSF (not seen PSPO), calculate a Worst 3, Best 3, and Average 3 estimate. They then use this to help them order the backlog for nice to have (optimistic) and must have (pessimistic). This is basic product planning man… nothing for the team to worry about…

  • Pingback: TFS 2013 Prozess Templates im Vergleich | Karsten Kempe – Visual Studio ALM()

  • Darren Carter

    Excellent article. 1 question: When you say “Completed & Original Estimate”, I’m not clear on the Completed aspect. I understand having a field for Original Estimate but what exactly is the Completed? Is that a percentage? Does it actually mean “Completed Estimate”? Please elaborate a bit on this aspect. Thanks in advance.

    • ttutko

      I believe what this means is that when you perform work on the PBI, you update it with how many hours (Or whatever time unit) you spent working on it. That way you can see at the end how good your original estimate was compared to how long it actually took to complete.

    • @ttutko:disqus is correct, however I personally do not see the value in “Original Estimate”. adding “Completed” that you update as you do work allows you to create a poor mans ‘percentage complete’. You add them together to get a totally fictitious total and then you get a percentage of “Remaining”. Gives you a nice graph.

      Reality is that as these two fields tend to be used by Project Managers to support their lies and spin, and I let them have it. It removes an argument from them against the Scrum template and enables the teams to get on with delivering work in spite of the PM’s best efforts. 🙂

      Slightly sarcastic but totally realistic.

  • Pingback: Avoid the Bug as Task anti-pattern in TFS - naked ALM - Experts in ALM, TFS & lean-agile with Scrum()

  • mjcarrabine

    Excellent article. Would you please elaborate on the issue with “resolved” in the Agile template, and what the better practice would be? Thank you.

  • Hi, great post!

    I am choosing right now what template would be the best choice for my team and this post will be very usefull for us, thank you!

    I have only one question, what do you mean with “Resolved (Code Complete and Unit Tests passes)”? I’m relatively new in the world of agile methodologies (but I’m a programmer and I know and I do unit testing on the other hand) but I don’t understand this point in the context of the Agile and Scrum templates in VSO.

    Thank you!

    • Its another way of saying “ready for being thrown over the wall to my test team whom I never talk to”…

  • Ianrehd

    HI, Thanks for this post. We have run a project for six months now with MSF for Agile template. But after reading your post I would rather go to VS Scrum template. How should I proceed to move from one to another ? Any guidelines somewhere ? Thanks.

  • Andrei

    Thank you for your posts – helps a lot in planning TFS implementation.
    I think it is useful to post link on how to perform suggested optimizations.
    I found one on Completed & Original Estimate by Colin Beales – http://blogs.msdn.com/b/visualstudiouk/archive/2013/04/18/adding-completed-work-to-the-scrum-2-x-template-including-reporting.aspx

    I wasn’t able to find instructions for the PBI Type customizations – looks like have to figure it out myself 🙂

  • fuulaluuf

    by the way, you can now put bugs on the backlog in the Agile template

  • Heloisa Reis

    Nice article Martin. I agree with you, we using Scrum is very nice. I have a question, we need metrics. I can customizing the template and added completed work.
    How can do configuration to TFS calculated automatically value and show in my release management report?

    • 1) Which release management report 🙂
      2) As long as the Completed work field is configured to report as a “Measure” you can use any of the reporting tools Excel or SSRS to show that figure and sum.

      You can’t get anything in the web access yet.

      • Heloisa Reis

        Martin,

        1) Burndown and Burn Rate reports (I need to know the completed work for each PBI on Scrum Template)

        2) I’ll check this cause I configured on completed work in Task but “measure” value not showing.

        Thank you for your help
        Best regards.

        • The Scrum template default reports don’t use that value. You will need to customise the report to include it.

          • Heloisa Reis

            Martin,

            Do you know about material how can I do that?

  • Rajarshi Basu Roy

    Hi Martin, the article was really useful and cleared a lot of “how others are doing” questions from my mind. But I got a little confused about your recommending CompletedWork and OriginalEstimate on top of Scrum 2.0 and then making comments like “they are used by Project Managers to support their lies and spin” and “comparing your original estimate with ‘reality’ rarely provides any value :)”.

    I have been studying Agile for adopting in my Product Development organization where –
    1) The technologies used in the product (since last 12 years) are Oracle Forms 6i, VB6, VB.NET, C# WinForms and now finally C# Web (Single Page Application with ExtJS) is being introduced to bring them all to single platform. There were compelling reasons for adopting these technologies during different phases of the product in last 12 years.

    2) Multiple teams are working on the product (.NET, Oracle Applications, Database, Testers, Systems/DevOps, Domain Experts)
    3) The total team size is more than 60

    You can imagine, trying to adopt Agile at that scale has become a very challenging task for me. We have started training and working for last 2-3 months with TFS 2013. We have adopted the Scaled Agile Framework with Feature-PBI hierarchy. We have got immense help from your “Teams Without Areas” article which MS has adopted well in TFS 2013.3.

    With my little knowledge and understanding I found values in CompletedWork and OriginalEstimate as below. I have been running around the internet to find any information about how the developer communities are using them and whether they are finding values too.

    As per my observations Scrum 2.0 falls short to answer the following questions. The questions may not be pertinent to all teams.

    1) Scrum 2.0 does not help you in improving your estimates over a period of time by allowing you to compare your ‘OriginalEstimate’ to any sort of actual values, say ‘CompletedWork’ at the end of a task.

    2) Scrum 2.0 does not help you derive the cost of a feature (from a businessman’s perspective) by summing up the hours consumed (multiplied by average hourly rate) so that marketing and sales strategies can be aligned accordingly. Estimates may not be very accurate but you can still get a fair idea.

    3) A burn rate chart in addition to a burn down chart gives excellent value to get an overall idea about whether the whole team is clocking more or less hours than average over a period of time.

    4) In a large team, despite of all agile philosophies like ‘Self organising’ and ‘Self disciplined’, some sort of accountability is required. It becomes difficult to trace where did your efforts go when the burn down chart is not moving down. For example, on Day 3 of a sprint the remaining hours were 100 and on Day 4 also the remaining hours were 100. So what have you done on Day 3. You must have been engaged in some other tasks which were logged and done the same day, e.g. 80 hours of tasks were added and then burnt. The tasks may be a) New Development Task b) Production Support Task c) Non Development Task (meeting, training etc.). We have separate PBIs like ‘Production Support’ and ‘Trivia’ in every sprint and we log tasks against them. Then having CompletedHours logged for the tasks helps us get the full picture. I am yet to organize the reporting, but at least I have tried to capture a little more data than Scrum 2.0 captures by default.

    I thought of implementing TFS Time Tracker TimeSheet add on but later thought that might be an overkill. I have put the idea on hold for now.

    Ideas? Suggestions? Do you think we are on wrong track?

    • I enjoyed reading your observations and if my answer here is not doing your question justice then feel free to email me. I am not really sure what you mean by “Scrum 2.0” as I have not ever heard that term. If you could clear that up I would appreciate it.

      There is little value in monitoring original vs completed on a software team. And making those estimates more accurate over time does not provide any value to your stakeholders. You are correct that the burndown helps the team understand where they are on their plan to complete the current Sprint Goal, but it is only an indication. The only people that should care/look at the Tasks and the Hours are the Development Team. I would consider it an organisational dysfunction if any of that information, while available, is used in any way outside of that Development Team. The Development Team is focusing on delivering working software and the daily plan, created at the Sprint Planning event and updated daily at the Daily Scrum, is just a plan and can change at any time.

      Above the Development Team we should be looking at value delivery. Your Scrum Team’s Product Owner should be focusing on both value and effort for delivery.

      It should like your organisation has low trust, another organisational dysfunction, and the accountability should not be on the accuracy of the estimates but instead on the progress towards the Sprint Goal. The Development Team is accountable and responsible for delivering, to the Product Owner, on that Sprint Goal. That is where the accountability is achieved and the Development Team needs the flexibility and freedom to figure out how to achieve that any way that they please without intervention.

      The act of “just making sure” that the Development Team is “on track” is what is preventing your teams from moving to self-organisation and beyond to self-managing. I think that you should focus on delivering value, now what needs to be done to achieve it. You will never have high performing Scrum teams until you do.

      Do not attempt Time Tracking in TFS. It will be a car crash as TFS is not designed for this sort of data. You should however be able to tell the difference between capex and opex for financial purposes. I would recommend that you use another system to reflect weekly time on Project and capex/opex for each of the teams. This can be done simply and is different data than that reflected in TFS.

  • Ed Kelly

    I realize this thread is old, but since I’m new to Visual Studio and came across this discussion.
    Being a long time Agilist, I disagree with Martin’s analysis of the two VS process templates. I agree with the comments about not hiding bugs. This is a definite no-no with Agile. However this is easily fixed by reconfiguring the workflow to treat bugs the same as User Stories.
    The objects are only part of the picture. The diagram that you don’t show Martin, is the object workflow. The Scrum workflow is very oriented towards planning and makes it difficult to track the progress of a Story or PBI or whatever label you choose (those are semantics to me). The Agile workflow recognizes that there are two steps to a Story being “Done”. 1) Being built and tested by the development team. 2) Being accepted by the Product Owner. I would use the Resolved state to represent the team being complete with all development work, including testing (I’m not sure why you think the Agile process implies only unit testing). The Closed state means that the PO has accepted the work. Any further changes would require another backlog item.
    I should note that the Scrum process follows the guidelines of Scrum.org and the Agile process follows the guidelines of AgileAlliance.org. Both of them include the thought leaders on Agile and Lean, but they are competing organizations and so naturally need some differentiator to sell their ideas.

    • You are entirely incorrect about the Agile template Ed. It was developed to follow the Microsoft Solution Framework (MSF) and the definition of “Resolved” in the template documentation is “code complete and ready for test”. As i have said, you can do agile with the MSF templates, but agile is antagonistic to their design.

      Additionally if you are following the Scrum Guide you should note that the Product Owner approves the Increment, and not an individual PBI. While sole teams will engineer a way to turn PBI on or off there is no requirement for it. Although i like that way of doing things.

      The focus, during the Sprint Review, on a PBI is to determine how one needs to update the Backlog, based on the latest increment, in order to reflect the next most relevant piece of work. If the PO does not like what has been created they can put a PBI to make it what they do want at the top of the Backlog.

    • I should also note that the Agile Alliance, Scrum.org m, and Scrum Inc all agree on a common definition of Scrum defined on http://scrumguides.com and maintained by Ken and Jeff.

      The Scrum template was designed from scratch by members of the Scrum community to comply with the Scrum Guide.

      • Ed Kelly

        Thanks for your quick reply Martin! I still don’t see anything in the Scrum Guide that precludes or is antagonistic to the MSF Agile process, except for the inclusion of a bug as a PBI (easily fixed). You’re correct that the TFS documentation considers an item “Resolved” when unit tests are complete, but that is also easily fixed by changing the word “unit” to “fully”.

        The Scrum Guide says only that the PO accepts a sprint. I would never wait until the end of a sprint to determine the acceptability of the work in it. The Guide does not preclude a PO from accepting individual PBIs. The Guide also says nothing about the concept of limiting WIP, which is a well established productivity practice. Having the PO accept PBIs allows the team to manage WIP, since a limited number of PBIs can be in progress (not Resolved) at a time. My favorite example for limiting WIP is a sprint that has 5 PBIs and on the last day the burndown has 5 units remaining. If each of these units is for a unique PBI, the sprint is a failure, i.e. none of the PBIs is complete.

        The process must also account for the real world where it’s not likely that sprints will be released at will. Most large development organizations group sprints into releases, to meet customer schedules or contractual commitments.

        I also don’t see the Scrum process as too restrictive (as you point out).The biggest difference I see between the Scrum process and the Agile process is in the workflow. The Scrum process is very oriented towards planning. The Agile process is very oriented towards execution. Why do we need states of “Approved” and “Committed” when by definition, a PBI included in a sprint backlog is approved and committed. On the other hand, how do stakeholders know which PBIs are being worked on, unless there’s an in-progress or “Active” state?

        I doubt that we’ll agree on these points, but if we ignore the semantics (like effort vs. story points), I think either process could be adapted by a perfectly Agile organization using Scrum.

        • Lol… So first the “scrum is restrictive” quote is from Microsofts documentation that I disagree with.

          You also just contradicted yourself twice. The Scrum Guide does indeed contradict at least two things in the MSF Agile template and has to be changed to a custome template to work at all. It’s then not the MSF Agile template and is then just another Scrum template.

          While these things are easily fixed in the MSF templates i find that it causes more friction than necessary for teams using it. It’s just harder to be Agile with either if the MSF templates. Especially if you take into account reporting which make the “easily fixes” things MUCH more expensive and complicated.

  • Pingback: Configure Visual Studio 2015 Community Edition and Visual Studio Online for Unity | What Up Games()

  • Lana Boltneva

    The conclusion is obvious – Dedicated Software Team model is the best value provided that you look at IT sourcing as a long-term strategic function allowing both cost saving, effective budgeting of IT projects and strong skills exchange. For more information and practical tips on the effective setup of a Dedicated Agile team check out this blog post as well as this webinar recording. http://intersog.com/blog/agility-team-management/fixed-price-time-and-material-or-dedicated-agile-team

  • Pingback: Dew Drop - May 17, 2017 (#2481) - Morning Dew()