@ClemensReijnen

Recent posts

Tags

Categories

Navigation

Pages

Archive

Blogroll

    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    Decks: TFService Basic and Advanced

    Decks I used Yesterday for a TFService presentation. Normally it is a demo only presentation, but a scheduled maintenance made me use them Sad smile (see http://blogs.msdn.com/b/tfservice/ for the schedule).  Lucky me I have them, now you have hem too…

    First presentation (second in the series, first session was about scrum 101) is some general usages of TFService and how it supports an agile way of working.

     

    Second deck (fourth in the sessions series, third one was about how we use it in real projects) is about how we solved some usages challenges like multiple backlogs, bug backlog, testing etc.

     

    Some more reading:

    1. http://www.clemensreijnen.nl/post/2011/10/09/Teams-in-VS11.aspx
    2. http://www.clemensreijnen.nl/post/2011/10/10/Teams-in-Visual-Studio-11-feature-teams-and-backlogs.aspx
    3. http://www.clemensreijnen.nl/post/2011/10/12/Teams-in-Visual-Studio-11-CTP-the-Bug-Backlog.aspx
    4. Teams and TFS Groups in TFS11, the backlog, board and security settings.

    06. Getting Testing Done in the Sprint – PBI Implementation Sequence

    A challenge in getting testing done in a sprint is the fact that the software (PBI) isn’t ready to be tested till implementation/ coding is done. 

    How To.
    Work on completing each item in the sprint backlog and finish one item after another, see task boards below.

    BAD -- Not able to start testing task board, every team member works on a different pbi. Testing can only start at the end of the sprint.

    image

    GOOD -- Ready to start testing task board, team members work together on a pbi one after another till it’s done. Testing can start early.

    image

    It is a good practice, but not often followed. it really helps getting testing done.

     

    Past Tips:
    01. Getting Testing Done in the Sprint - The Team and Activities
    02. Getting Testing Done in the Sprint – Regression Test Sets
    03. Getting Testing Done in the Sprint – Test Automation
    04. Getting Testing Done in the Sprint – Undone Backlog Item
    05. Getting Testing Done in the Sprint – No Double, Triple Testing

    Next Tips: 
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests
    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
    09. Getting Testing Done in the Sprint – Test Tasks on the Board
    10. Getting Testing Done in the Sprint – Done
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

    05. Getting Testing Done in the Sprint – No Double, Triple Testing

    One way of getting testing done in a sprint is making it [testing] as efficient as possible, meanwhile this also saves money. One way of getting more efficient is not doing things double or triple. An interesting thing with testing, we do test double or triple. We test it during unit, during unit integration, during functional and during acceptance testing, this can be done better, we could save a lot of time. I’ve seen teams which also automated all these types of tests, testing the same thing... not really efficient, they didn’t manage to get it done in a sprint.

    Each phase of the development process has its own test goals and depth of test coverage. The depth particularly depends upon the risks: higher probability of damage requires better test coverage. These test goals are especially aimed at discovering errors that can be found in that phase (“as early as possible”).

    • during unit testing the internal logic of the unit is tested,
    • the unit integration test needs to show that units ”understand” each other.
    • the system test needs to prove/demonstrate that the system complies with the functional requirements that have been agreed to,
    • finally, the acceptance test considers how the system fits into the environment in which it will operate.

    Test goals and (depth of) test coverage per phase are made compatible with each other using a Master Test Plan (see TMap® www.tmap.net).

    clip_image002

    Every test must be able to rely on previous tests, only then will the complexity of errors be contained to errors that were introduced during the last step. Setting up a learning cycle makes it possible to correct shortcomings, if any, in the testing process chain.

    Each phase of the development process and its corresponding test goal introduces a specific role with specific abilities and tasks. These roles are supported by specific ways of testing, often visualized in the Agile Test Quadrants.

    image

    http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/

    How the quadrants work

    Tests on the left-hand quadrants help the team know what code to write, and know when they are done writing it. Tests on the right hand side help the team learn more about the code they’re written, and this learning often translates into new user stories and tests that feed back to the left-hand quadrants. Business stakeholders define quality criteria for the top two quadrants, while the bottom two quadrants relate more to internal quality and criteria.
    from:
    http://readytohelpfortesting.blogspot.com/2012/01/ttesting-quadrants.html

    How To.

    All these types should work together, and as already mentioned a Master Test Plan (see TMap® www.tmap.net) can help. What also can help; is getting the team together and discus it [what to test where]. This is even more important when the first tip isn’t in place (01. Getting Testing Done in the Sprint - The Team and Activities) or when there is a Customer Test Team (will be explained in tip: 11. Getting Testing Done in the Sprint - The Customer Test Team).

    I like the example: where it is very hard to create unit tests for a specific piece off functionality, like login screens. To create unit test you have to use a mocking framework that mimics the user database or AD. This takes some time implement and maintain, while the functional testers will use the login screen (and test it) every time they run a test. A nice piece of functionality to have a good discussion with the tester where to test and automate this.
    An other example is a really world scenario I’ve seen; this is where the developers created some great unit tests for input validation, the functional system testers created test scripts to tests the input validation and the acceptance tester tested the input validations... really a scenario where there wasn’t any communication between the testers and people didn’t trust each other (see 01. Getting Testing Done in the Sprint - The Team and Activities)

    More reading: the Test Automation Pyramid http://blog.goneopen.com/2010/08/test-automation-pyramid-review/

    Tool Support:

    All test types are supported by VS2010.

    • The development tester:
      This tester knows the inner workings of the system and makes use of test-frameworks to automate the tests that he wants to perform. This testing role, has been supported for a while now by technical aids as unit test frameworks in Visual Studio, and is primarily done by developers. VS2010 eases the life of the development tester by intelligent support of Test Driven Development.
    • The system tester:
      The system tester tests the system for completeness, whether requirements have been met. These are not only functional requirements, but also quality requirements like performance and security (see agile test quadrant).
      System testers use a lot of scripts to automate their activities, he/she would like to perform the same tests using various infrastructures and configurations. VS2010 has had Load- and Web testing for quite a while in the Test Edition and with the introduction of VS2010 the creation of test scripts is simplified by introduction of the ‘Coded UI’ framework.
    • The acceptance tester:
      The acceptance tester, also called user tester or black box tester, truly is a tester who performs a test of the application and knows nothing about the internal workings of the application. He/she constructs test cases using functional requirements, using various testing techniques.
      Acceptance testers, who often still use Excel sheets to perform their tasks, are abundantly well supported in Visual Studio 2010. Test cases are registered in TFS and he/she has access to Microsoft Test Manager on optimal support of, usually, manual testing activities.

    There isn’t any support to see if pieces of functionality are tested twice. But with unit test coverage and data diagnostic adapters for functional testing there are some capabilities in place to extract the information from the system. Maybe time to create a custom data diagnostic adapter, visualize it and compare it with the unit test coverage.

    Past Tips:
    01. Getting Testing Done in the Sprint - The Team and Activities
    02. Getting Testing Done in the Sprint – Regression Test Sets
    03. Getting Testing Done in the Sprint – Test Automation
    04. Getting Testing Done in the Sprint – Undone Backlog Item

    Next Tips:
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests
    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
    09. Getting Testing Done in the Sprint – Test Tasks on the Board
    10. Getting Testing Done in the Sprint – Done
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

    04. Getting Testing Done in the Sprint – Undone Backlog Item

    A tip straight from the previous Scrum Guide (The guide updated and the undone TIP is removed, read The 2011 Scrum Guide – A Lot of Changes! ). But, the TIP still works, although it isn’t an ‘official’ tip anymore…

    Undone End to End Testing

    End to end testing, is not an agile specific testing practice, it’s a common sense testing practice. Create test cases to detected defects anywhere in the chain. This type of testing has been growing the couple of years enormous due to the rise of Service Oriented Architectures and more recent Cloud Computing.  as the TMap end-To-End Testing books describesketentesten%20EN_tcm9-57123

    “End-to-end testing is a form of testing in which the (business) process is tracked through an interconnected series of systems, which may be based in different organizations, aiming to answer the following questions:
    - Does the IT process support the business process adequately? - Are the process and systems integrated with each other in the right way?”
    TMap.net End-To-End Testing

    End-to-End testing is seen as a challenges in Agile environments, with the most important challenge that systems under development aren’t ready for End-to-End testing. Not every service is finished to test the complete end-to-end business process. Stubs are a solution, but can these be made in the current sprint and are stubs good enough to say something about the quality of the system. And, when the system are ready and a change in a service is needed, how and can we re-run all the end-to-end tests, is there time enough.

    All these challenges with end-to-end testing in agile projects can be summarized in two topics:

    • Not Ready Systems in a Sprint

    • Not Enough Time in a Sprint

    tipScrum solves this problem, this problem of not able to be compliant on the definition of done at sprint finish, by defining ‘Undone work’. the scrum guide mentions this in a TIP and in the final thoughts of the scrum guide

    Some organizations are incapable of building a complete increment within one Sprint. They may not yet have the automated testing infrastructure to complete all of the testing. In this case, two categories are created for each increment: the “done” work and the “undone” work. The “undone” work is the portion of each increment that will have to be completed at a later time. The Product Owner knows exactly what he or she is inspecting at the end of the Sprint because the increment meets the definition of “done” and the Product Owner understands the definition. “Undone” work is added to a Product Backlog item named “undone work” so it accumulates and correctly reflects on the Release Burndown graph. This technique creates transparency in progress toward a release. The inspect and adapt in the Sprint Review is as accurate as this transparency.

    Within the Visual Studio 2010 Scrum process template this means that you have to link or create tasks to a specific ‘Undone Work’ product backlog item. this ‘Undone Work’ product backlog item accumulates the undone work regarding to End-to-End Testing (and others) over time and can be monitored just as other backlog items.

    http://www.slideshare.net/xwarzee/path-to-agility-ken-schwaber 

    image

     

     

    Tool Support

    In TFS with the Scrum process template we can create Backlog Items very easy.

    image

    So, creating an undone backlog item isn’t that hard, the challenge is take it with you every sprint. for example in my undone backlog item I’ve got some undone tasks from sprint 1 and some from sprint 4. The iteration paths for these tasks still point to the sprint 1 and 4 sprints.

    image

    This will result in a wrong sprint backlog, because the tasks who point to other sprints as the current sprint won’t appear in the sprint backlog. So, when moving this Undone backlog item to another sprint because not all tasks are done, you also have to change the iteration path for the corresponding tasks.

    image 

    Just keep in mind TFS doesn't update the hierarchy, you have to do it manually (or use Excel, my favorite).

    Past Tips:
    01. Getting Testing Done in the Sprint - The Team and Activities
    02. Getting Testing Done in the Sprint – Regression Test Sets
    03. Getting Testing Done in the Sprint – Test Automation

    Next Tips:
    05. Getting Testing Done in the Sprint – No Double, Triple Testing
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests
    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
    09. Getting Testing Done in the Sprint – Test Tasks on the Board
    10. Getting Testing Done in the Sprint – Done
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

    03. Getting Testing Done in the Sprint – Test Automation

    Automate your testing effort, or better your test execution, is a must to get your testing done during the sprint. Automate your test execution shrinks the time needed to execute the tests, which leaves more time for the team to specify new test cases. On the other hand it also brings some inflexibility in your testing, you need to maintain the test automation code and update it when functionality change, which again cost time which the team better could use to specify and execute test cases.

    How to.

    So, there need some strategy what to automation and how to automate. The decision what test cases are candidate for automation depend on several decisions. For sure the regression set is a good candidate (see Tip 02. Getting Testing Done in the Sprint – Regression Test Sets) which is a collection of test cases based on risk classifications and business value (see TIP 07. Getting Testing Done in the Sprint – Risk and Business driven Tests).

    With test automation you also must take in to account that the test cases is automatable, maintainable and has some ROI. Together with this ROI of test automation also comes the design for testability. It should be easy to create test automations, the design of the application should have this in its design and architecture.

    How many, how much effort you have to put in test automation has several investment levels. From zero completely no investment till, a very high investment of changing the architecture for testability and automate s many scenario's as possible.

    Tools support.

    See this video for the Visual Studio test automation support.

    image 

    Also Visual Studio test automation support has several investment levels, in the presentation below at slide 38 and 39 these levels are discussed. The rest of the presentation discusses the different tactics of test automation with Coded UI.

     

    Past Tips:
    01. Getting Testing Done in the Sprint - The Team and Activities
    02. Getting Testing Done in the Sprint – Regression Test Sets

    Next Tips:
    04. Getting Testing Done in the Sprint – Undone Backlog Item
    05. Getting Testing Done in the Sprint – No Double, Triple Testing
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests
    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
    09. Getting Testing Done in the Sprint – Test Tasks on the Board
    10. Getting Testing Done in the Sprint – Done
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

    02. Getting Testing Done in the Sprint – Regression Test Sets

    Some teams rerun every test every sprint, this is time consuming and isn’t worth the effort. Having a clear understanding what tests to execute during regression testing raises the return of investment of this testing effort and gives more time to specify and execute test cases for the functionality implemented during the current sprint.

    How To.

    So, collecting a good regression set is important. There area lot of approaches how to get this regressions set, most of them are based on risk classifications and business value (see TIP 07. Getting Testing Done in the Sprint – Risk and Business driven Tests).

    From “A good regression test is invaluable.

    The principle is that from each test case a collection of additional data is determined into the test cases for the regression test are ‘classified’. Using these classifications all cross sections along the subsets of test cases can form the total test that are selected.

    Automation of this regression set is almost a must (see next TIP 03. Getting Testing Done in the Sprint – Test Automation).

    Tool support.

    Microsoft Test Manager has an interesting capability to control the amount of regression testing that need to be done during the sprint. the data diagnostic adapter “Test Impact”, it give information about test cases which are impacted by code changes

    Recommended Tests

    and see page 63 of the training guide http://www.slideshare.net/clemensreijnen/mtlm-visual-studio-2010-alm-workshop

    How to create a regression set in Microsoft Test Manager.

    Read:
    Guidance for Creating Test Plans and Test Suites and read this http://blogs.msdn.com/b/anutthara/archive/2010/09/22/guidance-for-creating-test-plans-and-test-suites.aspx and this Management, preserving and organization of manual test cases within VSTS 2010.

    One thing to keep in mind: In MTM2010 the copying of test cases between test plans copies the reference by default and not the test case. So, a test case can be referenced in multiple test plans and suites, changing a test step will change it on all locations. 

    Creating regression sets for developer tests and functional system tests are mostly more easy. Unit tests are small and run fast, so no problem to run them all. Unit Integration tests are a bit more challenging, you need to balance a bit more what to run when, but both developer tests and functional system tests, aren’t often the biggest bottlenecks in getting testing done in the sprint. When they are, try to do the same approach as mentioned above… balance what to run when.

    Past Tips:
    01. Getting Testing Done in the Sprint - The Team and Activities

    Next Tips:
    03. Getting Testing Done in the Sprint – Test Automation
    04. Getting Testing Done in the Sprint – Undone Backlog Item
    05. Getting Testing Done in the Sprint – No Double, Triple Testing
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests
    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
    09. Getting Testing Done in the Sprint – Test Tasks on the Board
    10. Getting Testing Done in the Sprint – Done
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

    01. Getting Testing Done in the Sprint - The Team and Activities

    Every Agile ALM presentation the same question is asked: How do I get testing done in a sprint?

    There isn’t a one solution/ practices/ to do/ how to fits all for this. So, I made a small list of tips you could do (or recommended to do, or must do… ), which can help to get testing done in a sprint. 

    Tip 1: Have testing knowledge in the team.

    Actually not a tip, it is a must. This is a kind of obvious but not common and I think the hardest thing to accomplish. It is: get testing knowledge available in your team. When you don't have it, you will fail.

    How to

    Now, it isn’t that easy to accomplish this collaboration. Test and dev are different, a nice quote from this ‘test’blog:

    In the D-world, the world of the Developers, we think Generalist Testers are pencil-pushing, nit-picky quality geeks. Mostly they are beside the point and are easily replaced. They seems to like making much noise about little defects, as if we made those errors deliberately....

    In the T-world we don't hate the Developers for their perceptions. We are disappointed about the poor quality of the software.
    Bad assumptions on the part of Developers are more to blame for the problems than are software weaknesses.
    We never(or seldom) get software what will work right the first time. No, in the T-world we think that developers forget for whom they are building software, it looks like they are building for themselves......

    Try to combine these two worlds in one team, you definitely need to come up with a Collaborative Culture:

    The three most important concerns are:

      • Trust.
        • a topic closely associated with trust when it refers to people is Identity.
      • Collaborative culture.
        • A collaborative culture consists of many things, including:
          • Collaborative leadership;
          • Shared goals;
          • Shared model of the truth; and
          • Rules or norms.
      • Reward.
        • a “reward” for successful collaboration is most often of a non-financial nature.

    Show me the value, seems to be the magic word.
    Test adds knowledge, knowledge during the grooming the backlog. Helping the product owner with defining proper acceptance criteria. And, help find improper written backlog items with inconsistencies for example. (this is my favorite test activity I didn’t know about before started reading TMap, Assessing the Test Base). In both ways helping the product owner and the team to focus on value.

    Tools support, Visual Studio 2010

    Tools can help, when using the VS2010 TMap Testing Process template you will notice that the test activities get an important place, helping the tester to get on board.

    The ‘Testing’ Tab with test activities, next to the implementation tab.

    Still two different worlds, test and dev in this way… but it give a good visual reward of being connected. Probably many teams won’t need an additional visualization of testing effort and can use the scrum process template in combination with their testing methodology, but this will help them to get started. 

    Interesting topic is the introduction of the manual test tool ‘Test Manager’ with Visual Studio in the current release. It helps teams to get more connected, it shows the pain points where the collaboration isn’t seamless. So, adopting MTM can be a good start for agile teams to get testing aboard. But, be aware the interactions are more important as tools. The tools won’t fix bad collaboration, mismatching identities, lack of trust and won’t give any reward.  

    Next Tips:
    02. Getting Testing Done in the Sprint – Regression Test Sets
    03. Getting Testing Done in the Sprint – Test Automation
    04. Getting Testing Done in the Sprint – Undone Backlog Item
    05. Getting Testing Done in the Sprint – No Double, Triple Testing
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests
    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
    09. Getting Testing Done in the Sprint – Test Tasks on the Board
    10. Getting Testing Done in the Sprint – Done
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

     

    Teams and TFS Groups in TFS11, the backlog, board and security settings.

    Back to the ‘teams’ topic, it is new in TFS11 … (see below the previous posts about this topic)

    1. http://www.clemensreijnen.nl/post/2011/10/09/Teams-in-VS11.aspx
    2. http://www.clemensreijnen.nl/post/2011/10/10/Teams-in-Visual-Studio-11-feature-teams-and-backlogs.aspx
    3. http://www.clemensreijnen.nl/post/2011/10/12/Teams-in-Visual-Studio-11-CTP-the-Bug-Backlog.aspx

    Beside using the new team concept in TFS11, you also just can do it the ‘old’ way. Put all your team members in the different TFS Groups (readers, contributors, … ) and give them access to the team project. Just as you did the past decade. But, you have to understand what happens when you do it. You also can mix things, create teams and only add TFS groups to it, or give people specific rights within a team… actually you can make it a complete chaos. In this post some usages scenarios. (at the end of this post a final conclusion, maybe you want to read that one first.)

     

    Scenario 1: A team project with no teams and only team members in TFSgroups configuration.

    When you create a team project, you get by default a team with the team project name, prefixed with ‘team’. This default team has one member, the creator of the team project. Which as you can see I deleted.

    image

    When you browse to the administration page, you will notice that you can’t delete the default project. but, with no members it can’t do any harm.

    image

    Next, you can start adding members to the different TFS groups. For example I added several people to the contributors group.

    image

    Following step, make security settings for the different groups... for example for the iterations

    image

    or the areas. You can find it at the same places as you can in VS2010.

    image

    Interesting is that the security settings for the source repository only can be set in Visual Studio.

    SNAGHTML3c7f460

     

    When you have a team project without a team (beside the default team), you do have a backlog, with a board.

    image

    Everything works as expected, only the capacity planning seems to be broke. The ‘only members in tfs groups’ project gets a bit more complicated when you start working with area’s. For example add two sub-areas and mark one of them as current.

    Good to know when you mark the parent area as the current one you can set a child area as default. When adding backlog items by using the backlog it will automatically set the area property. 

    image 

    Doing this and adding PBI’s and backlogs to the this area. Will result in a new backlog and new task board, helping the team members (which are only in TFS groups) to focus on this specific area only. Set the area setting to the parent area, including all sub area.. will result in a combined backlog.

    The only thing what stays the same when changing the areas for your team project are the Team favorites (we don’t have a team :) and the queries behind it don’t have a current area path clause. You could add it yourself.

    image

    Conclusion

    It is possible to create projects without using the new Team concept. Things look a bit strange, we have team favorites but no team members for example. But the main functionality works. It only gets a bit complicated when you start using areas and make different people responsible for different areas. You have to swap between the admin page and the home screen when you want to see a different backlog / functional area.

    Scenario 2: teams only

    image

    I created two additional teams for the two different areas, added the team members to the default team and added the default team to Team 1 and 2.

    All teams are in the contributors TFS group, resulting in the fact that all team members have the same security settings.

    image

    Having you teams setup in this way, gives them the easy capability to swap between the teams. The backlogs are up to date and the team capacity planning works. One annoying thing, the team favorites, the work item queries, are the same for the whole project so I have to create queries for every team and add them as team favorite.

    image

     

    Scenario 3: teams with tfs groups

    Another scenario, for playing with security, teams and TFS groups is… adding the team members to TFS groups and add these groups to the teams as members. Now, you have members in your team with different security settings. Doesn’t feel really scrum, but it works.

    image

    Only the TFS Groups Readers and Contributors in the the default team and Team 1 and 2 have only the default team as team member.

    image

    Scenario 4 and 5 Teams with team members with specific security settings. 

    The last scenario, is where you add only users to your team and set explicit security settings per team members.

    image

    I won’t recommend this, you really can’t administer this.

    Final Conclusion.

    So, after this small journey across the different possibilities of configuring security settings in TFS11, I must say… Be careful, you can create chaos which you aren’t able to administer anymore, and think up front about your areas and team structure, it influence the usage and capabilities of the nice agile tools.

    • Scenario 1: No Teams only TFS groups with Team members.
      You can use the backlog and task board,  the capacity planning doesn’t work (yet?). It gets complicated with multiple areas and multiple backlogs. For example when you want to use a bug backlog, don’t use this scenario go for number two or three.
    • Scenario 2: No TFS groups only Teams with Team members
      This feels like the only real agile solution, all team members have the same security settings and the usages of multiple backlogs is easy.
    • Scenario 3: Teams with TFS Groups with specific security settings
      When you want to have team members with different security settings, this is the way to go. Areas and multiple backlogs are fully functional including the capacity planning.
    • Scenario 4: Teams with Team members with specific security settings
      Forget this one… you will go crazy over time
    • Scenario 5: Teams with Team members with specific security settings and with TFS Groups with specific security settings.
      You not only will be crazy you probably will have to go to the hospital when you try to maintain this scenario.

    For now… number three is my favorite, number two is more pure… one is ok, four and five not ok.

    TFS11 Scrum board update remaining work without opening the work item…

    Very nice MSFT added the capability to update the remaining hours without having to open the work item. and even more nice it has some intelligence behind the drop down, because it populates the dropdown list with values in range.

    image

    TFS11 on Azure January 2012 update – request feedback

    The latest update on TFS ( see: Team Foundation Service Planned Maintenance Tues Jan 17th ), fixed an issue with builds, they look stable again. And my Azure build service executes them happy. Now its time to expand this scenario with test controllers and test agents for automatic test execution and test environment provisioning.  

    image

    But, I want to point to the new menu item ‘request feedback’ … it is the feature for getting early feedback about your product, for example during the sprint review.

    Picture1

    It is a really nice feature supported with a tool similar as the Test Professional, Test Runner. 

     image

    More explained with a walkthrough for the dev preview can be found in Brian Kellers dev11 VHD and the handson lab: Building the Right Software - Generating Storyboards and Collecting Stakeholder Feedback with Visual Studio 11 (docx).

    How it works, I can start asking feedback … about a feature I just created. For example in this screen I’m asking if Brad the Product Owner can look at the website for typos.

    image

    It generates an email for Brad, asking to start the feedback session.

    image

    Now this is where TFS Azure isn’t complete, it can’t send the mail and the feedback tool URL points to the MSDN subscriptions download page. But, when you look at the Brian Keller hands on lab you know what happens.

    there isn’t a feedback work item type..

    image

    image

    A very promising feature, special in distributed teams and with TFS on Azure we can ask any one for feedback.

    So, get your product owners informed… they will get involved in dev11.