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

    A Product Owner read up.

    A small reading covering the role of the Product Owner in agile teams.

    What does the theory says about the Product Owner’s role?

    The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

    The Product Owner is the sole person responsible for managing the Product Backlog. Product

    Backlog management includes:

    · Clearly expressing Product Backlog items;

    • Ordering the items in the Product Backlog to best achieve goals and missions;
    • Ensuring the value of the work the Development Team performs;
    • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
    • Ensuring the Development Team understands items in the Product Backlog to the level needed.

    The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

    The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

    For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
    (Scrum guide | http://www.scrum.org/Scrum-Guides)

    -+-

    The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team.

    Each agile team, or in the case of large programmes an agile subteam, has a single product owner to go to for information and prioritization of their work and they do so right away.

    A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front (BRUF).

    The role of product owner was introduced to the agile community by Scrum, although the onsite customer practice of Extreme Programming (XP) is very similar. This role has been adopted by the Disciplined Agile Delivery (DAD) process framework.
    (The Product Owner Role | http://www.agilemodeling.com/essays/productOwner.htm)

    -+-

    The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed.
    (Learning Scrum - The Product Owner | http://www.mountaingoatsoftware.com/scrum/product-owner)

    How to recognize a good product owner?

    Collaborate with the team on an ongoing basis and to guide and direct the team.
    Empowered, and present.
    (Being an Effective Product Owner | http://www.scrumalliance.org/articles/44-being-an-effective-product-owner)

    Passionately about the customer of the product.
    (Who Makes a Good Product Owner |http://geekswithblogs.net/rakker/archive/2010/05/17/who-makes-a-good-product-owner.aspx)

     

    What are the needed capabilities for a Product Owner?

    A good product owner is a good negotiator.
    (Who Makes a Good Product Owner |http://geekswithblogs.net/rakker/archive/2010/05/17/who-makes-a-good-product-owner.aspx )

    Understand the technical decisions
    (Transitioning to Scrum: Selecting the Product Owner | http://www.construx.com/Retrospectives/Transitioning_to_Scrum__Selecting_the_Product_Owner )

    A thorough understanding of the customer needs
    (Being an Effective Product Owner | http://www.scrumalliance.org/articles/44-being-an-effective-product-owner )

    Planner
    (Skills a good Product Owner should Master | http://blogs.agilefaqs.com/2012/05/26/skills-a-good-product-owner-should-master )

    Knows the organization.
    (Qualities of a great product owner| http://www.scrum.nl/website/scrumblog.nsf/dx/7-qualities-of-a-great-product-owner )

     

    How to recognize good work from a product owner?

    The first artifact of an agile to look at when you want to know how they perform is the Backlog, and investigate if it is nice, clean and mature. If you want to know if the Product Owner is in trouble the backlog is also the place to look. Are there enough backlog items, are they well specified, are there acceptance tests etc …and are there backlog grooming sessions, with the product owner?

    The goal of the UED (and anyone else involved at the time) is to add detail to the story in a just-in-time manner. There is usually no value to splitting a large user story up now or stapling a document to it if we won’t work on that product backlog item for quite awhile. While working to add detail in a just-in-time manner, those doing so should strive to add just-enough detail that no individual item will take more than one sprint to complete. Just-in-time and just-enough become the targets for establishing a smooth flow from product backlog to sprint backlog.
    (Writing the Product Backlog Just Enough and Just In Time | http://www.scrumalliance.org/articles/87-writing-the-product-backlog-just-enough-and-just-in-time)

    Sometimes called StoryTime sessions, the purpose of these meetings is to make improvements to the Product Backlog.
    (How to Hold an Effective Backlog Grooming Session | http://www.scrumalliance.org/articles/339)

    Grooming the product backlog should be a collaborative effort that involves the product owner and the development team
    (GROOMING THE PRODUCT BACKLOG | http://www.romanpichler.com/blog/product-backlog/grooming-the-product-backlog/)

    What are the challenges when mixing roles or transform a role to Product Owner?

    It's important to understand that a piece of work can be done better by one whole person than by two half persons. Merging roles can lead us into strange situations. But Scrum guidelines clearly state that there are three roles: product owner, ScrumMaster, and development team. Scrum also demands 100 percent commitment from each of these roles. So if we merge roles, then it's simple: We aren't using Scrum. We should always mix our primary colors at 100 percent, rather than using uneven amounts of a variety of colors, to aim for white. We should not live with gray.

    ( Why Not Merge Roles in Scrum? | http://scrumalliance.org/articles/524-why-not-merge-roles-in-scrum )

    Developer as Product Owner:

    Developers like to develop features, technical challenging features. Beside that you see these challenging features bubbling up the backlog also the challenge will be the low level acceptance criteria, just due to the optimistic and code view of the developer.
    Trigger: Technical Items on Backlog, Scope Creep.

    Testers as Product Owner:

    Testers can be good critics of the backlog quality. For example, questions will be asked if the backlog items are good written down and if they have good clear acceptance criteria. Beside the quality view also a good understanding of the product and users will make testers an interesting mix with the Product Owner role. A pitfall can be that too much design up front, will testers want to tackle most of the unknown upfront.
    Trigger: big too detailed backlog.

    Manager as Product Owner

    It should be interesting to have your manager as a Product Owner. But for sure it wouldn’t be a good idea. Probably the knowledge of the product will be low. But more important the manager is your boss and when the boss wants something else you as a team member will probably listen although it is out of the sprint.
    Trigger: interference in the sprints

    Business Analyst as Product Owner:

    You often see that analysts is the Product Owner or that they become the Product Owner due to a missing Product Owner. Although they understand the system / product into detail, this isn’t a good idea. For analysts models / documentation are their primary artifact and often also single point of truth. This often results in the diagrams being the master over the backlog, which results in too many documentation and other challenges.
    Old habit: communicating via documentation
    (Where Do Product Owners Come From? | http://www.agilemodeling.com/essays/productOwner.htm )
    Trigger: diagram first, too much documentation.

    End user as Product Owner:

    The end user knows what he wants, but this doesn’t make him immediately a good Product Owner. A Product Owner needs to be available for the team all the time and needs to make visionary decisions with technical knowledge, something an end-users can miss during their daily work.
    Trigger: missing in action Product Owner, Scope Creep.

    Scrum master as Product Owner:

    Problems may arise when the PO is being pulled by the customer in one direction that is causing significant strife to the developers (because they need to build some other infrastructure first). The SM job is not to follow the whims of the customer but to protect the developers from their whims. Pulling this off objectively is hard.
    (#in comment: In Scrum, why shouldn't the Product Owner and ScrumMaster roles be combined? | http://programmers.stackexchange.com/questions/106966/in-scrum-why-shouldnt-the-product-owner-and-scrummaster-roles-be-combined )

    The Product Owner cannot be the Scrum Master. They both have clear interests and habits. Changing their individual habits is hard. Changing them so they can see both points of view is impossible. They first have to learn the new way of doing their job with agility.
    (Product Owners not proxies | http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/)
    Trigger: sprint interference.

    What are the most common problems with Product Owners?

    There is a big list of common Product Owner problems, for example when he is not available or that he doesn’t have the power to make decisions, or … see below a list of blog posts which covers them.

    AVOIDING COMMON PRODUCT OWNER MISTAKES | http://www.romanpichler.com/blog/roles/avoiding-common-product-owner-mistake/

    Product Ownership Antipatterns, or a character description of the PO from Hell | http://agile.dzone.com/articles/product-ownership-practice

    Open Space Notes: Building a Better Product Owner | http://www.scrumalliance.org/resources/357

    Your Product Owner Is Missing in Action — Now What? | http://www.scrumalliance.org/articles/509-your-product-owner-is-missing-in-action--now-what

     

    Product owner training

    Professional Scrum Product Owner Training | http://www.scrum.nl/training/Professional-Scrum-Product-Owner-Training-110224

    CSPO: An Introductory Course for Product Owners | http://www.scrumalliance.org/pages/certified_scrum_product_owner

     

    Testing in one week sprints, hierarchy backlog items and test coverage.

    One week sprints are great and bring big benefits to you team and product.

    The artifacts that are in your system will be; image the backlog with nice small backlog. That small that they can be realized in the one week sprint. your sprint will contain a image test plan for the sprint, with related product backlog items. Probably there also will be some image additional test plans for other concerns/ risks. The image regression test plan finally will contain a collection of test cases gathered from the sprint test plans and the additional test plans. And the customer will use a image acceptance test plan for there work.

     

    image

    This works great. And, because the PBI’s image with their corresponding test cases image are that small the team will have the continuous discussion if the needed validation should be implemented with unit test technology/ automated test or, if it would be easier/ faster/ better/ higher ROI to specify and execute the test as a manual test. Work around testing in this way makes it a real team effort which makes it easier to get testing done in the sprint.

    WP_000229  
    How should we test this PBI?

    The test cases during a sprint are that small that also the image regression set will become a collection of very small validations of the system. After several ‘one week’ sprints the bigger scenario / end to end test cases are missing. A collection of small validations made the team uncomfortable about the quality of the regression and unit test case set.

    For example: when making several settings the system behaves in a different way. In our situation is was the backend connection with either SharePoint 2007, 2010, 2013 or O365. Making this setting and saving this setting was one PBI. The different behavior according to this setting where other multiple PBI’s. And the overall collection of settings (all different PBI’s) made the system behaves different. We needed an Activity Diagram to explain its behavior.

    image

    The decision to make use of Parent PBI’s is easy made (we called them Features and prefixed them with this name).

    clip_image001

    Related to these ‘feature’ PBI’s a feature test plan can be created, which will cover the full scenario and all path coverage's. in this way giving the team the comfort that all paths and scenarios are covered.

    image

     

    Finally ending up with a bit more complex organization, but with a better test coverage.

    image Feature PBI’s broken down in child PBI’s, which are partly implemented in a sprint. A nice additional benefit is that the team focuses on Feature PBI after Feature PBI, implementing them one after another. image Activity diagrams support the scenario, and when needed use case or other UML diagrams. The overall scenario (activity diagram) is related to the Feature PBI and the different actions can be related to the child PBI’s. image Testers can use their Test Design Techniques when analyzing the UML diagram for test coverage and test cases. And the image regression set will be a mix of Sprint Test plan test cases and Feature Test plan test case.

     

    image

     

    Everything perfect. But the bit more complex organization of the backlog has its challenges. Not all PBI’s relate to a Feature PBI and often a PBI’s influences / relates to multiple Feature PBI’s. The one activity diagram per feature is fake and a theoretically example, the real world is more challenging. See also Martin’s post You can’t stack rank hierarchical work items?.

    Although it will give you some extra backlog grooming activities, still Features PBI’s can bring benefit to the system. Don’t try to make it too perfect and definitely have testing knowledge in place for the coverage then it is a good thing to give it a your bigger systems.

     

    6 Testing with Visual Studio 2012 Agile TMap _ The QUALITY A-Z Roadshow

    The QUALITY A-Z Roadshow:
    A full day overview, with demo’s and real world experiences of all the testing capabilities of Microsoft Visual Studio and needed testing practices.

    1: Keynote: The Value of Quality
    2: Test Planning
    3: Test Specification and Execution
    4: Test Controlling and Reporting
    5: Test Infrastructure and Virtualization
    6: Operations Integration



    Feel free to ping me if you want to have these sessions delivered at your company.

    Posted: May 12 2013, 14:07 by ClemensReijnen | Comments (2) RSS comment feed |
    Filed under: ALM | Agile | MTM | SCRUM | TMap | VS2012

    10. Getting Testing Done in the Sprint – the Definition of Done

    Are we done? When this is unclear the team will do too less or too much. Both are bad. The Definition of Done helps to define when you are done, the same as a master test plan helps to define the test levels. A good definition of done specific for your team and project will definitely help knowing when you're ready and to get testing done in a sprint. Mainly because you know when you're done.

    Making a good definition of done is a trivial task and books are written about it.
    A good starting point are these posts:

    One thing I really like to keep in mind when defining a Done List are:

    • Risk Analysis, and together with this the Master Test plan. I should be clear what the risks are and what the impact is on when you are done.
      You can think of Done ListItems, which help understand the level of testing to be done, like:
      • All High Risk BPI’s have a test coverage of ..% and no open bugs
      • All high prio test cases are automated
      • Low Risk, Low Business PBI’s may have 10% open low impact bugs.  
    • Test Levels, balance the unit, functional and acceptance testing and define where what is tested. Definition of Done items like; all unit tests are green, all functional testing is done or all written acceptance tests are executed, are unclear. How many tests should we write to be done? Code Coverage is one for unit testing, but how do you know when your done specifying functional tests and acceptance tests. So, writing down in the Done list that testing is done isn’t enough it also should have a statement about when test writing is Done.
    • When are we done creating the Regression Set and when are we done with Test Automation

    So, when testing is important and you don’t want to create a random amount of test cases for each PBI, should mention it in the Done List, and for sure make the validation automated with a build system.

    image

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

    Next Tips:
    11. Getting Testing Done in the Sprint - The Customer Test Team
    12. Getting Testing Done in the Sprint – The Test Branch

    08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests

    During release planning meeting. Capture acceptance criteria and immediately add the as logical test cases to the PBI. It will help the team to understand, clarify the discussion and more important for this topic, it helps testers be involved, and be important at the early stages of the software cycle.

    Within VS11 | TFS11 this is very easy to accomplish:

    1. add the PBI to the backlog.image
    2. add logical test cases, from the backlog item work item. and only add the test case title.
      image
      image
    3. Start planning and execute the sprint
    4. open Microsoft Test Manager, add a test plan for the current sprint.
      image
    5. Add the Backlog items as Requirement Suites to the plan and see the test cases listed in the suite, ready to add test steps.
      image

     

    This is a very small tip, but is very useful to get testing involved in a sprint (see tip 01).

    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
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence
    07. Getting Testing Done in the Sprint – Risk and Business driven Tests

    Next Tips:
    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

    07. Getting Testing Done in the Sprint – Risk and Business driven Tests

    I really like the mindset “no risk, no test”. So, when there isn’t any business risk, there aren't any tests and is it easy to fit testing in a sprint. More realistic do a good risk analysis on your product backlog items before start writing thousands of tests. Also in scrum is risk an important attribute.

    The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain.

    Products are built iteratively using Scrum, wherein each Sprint creates an increment of the product, starting with the most valuable and riskiest.

    Product Backlog items have the attributes of a description, priority, and estimate. Priority is driven by risk, value, and necessity. There are many techniques for assessing these attributes.

    from the scrum guide

    Within the TMap test approach product risk analysis is an important technique. Determine risk analyses are part of the proposed activities in the Master Test Plan of TMap: ‘Analysing the product risks’. It not only supports the Product Owner to make the right decisions it also the Team benefits in a later stage, this information is invaluable while defining the right test case design techniques for the Product Backlog Item.

    “The focus in product risk analysis is on the product risks, i.e. what is the risk to the organization if the product does not have the expected quality? ”
    www.TMap.net

    Having full product risk analysis for every Product Backlog Item during the Release Planning meeting is slightly overdone, but the major risks should be found. Determine product risks at this stage will also provide input for the Definition of Done list.

    3

    TMap Product Risk Analyses

    Within the Visual Studio Scrum 1.0 Process Template Product Backlog Items are written down in the Work Item Type ‘Product Backlog Item’. This Work Item Type hasn’t got a specific field for risk classifications. Adding a risk field is preferable (TFS Powertools makes this an easy task) so you can query on this property, or you can make the risk analyses a more product generic property.

    image

    TFS Scrum Product Backlog Item

    The flow with risk analyzing, classification, discussion and test design with the Product Owner can look like the diagram below.

    image

    But again most important for fitting testing in a sprint, know the risks use test design techniques to cover the risk and only write useful test cases.

    Post partly taken from previous posts:

     

    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
    06. Getting Testing Done in the Sprint – PBI Implementation Sequence

    Next Tips:
    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

    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

    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

    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.