How to use TFS 2015 Agile template artifacts in practice?

Question

I am part of a company that is just establishing our process methodology for using the SAFe version of Agile, and leveraging the TFS 2015 Agile process template. Our team has several questions regarding the proper usage of the artifacts. Primarily our teams consist of BAs, QAs, and Devs. The questions we are currently dealing with are:

1) User Story - Who creates the user story? - Should the assignment of the user story change through the life of the user story? (ie: BA creates the user story, then assigns it to the developer, who then assigns it to the tester...) Or should the user story always stay assigned to the creator and tasks get created underneath it that are then assigned to people to work on?

2) Tracking what is in a "release" - Our teams have been using an additional field created on the User Story to track a "Status", which contains things like "Deploy to ", "Deployed to ", "Deploy to "... etc. This is to help inform the testers of what user stories are available to be tested. We currently do not have a firm grasp on how to properly track this information. Some are arguing that this added field should not exist on the user story at all, while other are adamant that this Status field is more valuable than the native State field of the user story. The bottom line is, what is best practice for determining what is available to be tested in what environment? Perhaps we are doing Agile wrong and are not even close to hitting the mark here, so some advice and guidance in this regard would be appreciated.

I would appreciate if you could share your own experiences of what has/hasn't worked and/or point me to additional resources that help with the practical application of the TFS artifacts as they are used to track work along with code, testing and deployments. Thank you.

Answer 1

User Stories

Anyone can create user stories but only the Product Owner can prioritise them. It's also everyone's job to hel refine them to action.

Tracking what's in a release

A single status field on a User Story for environment is not really condusive to understanding either the state of the work item, or it's location in the flow. Ultimately your coders and testers should be communicating regularly on the same team, thus eliminating the need for tools to give you this information.

However this information is built into TFS. When a build is sucessfull then it's number is written into all the Work Items that are associated, and every parent of those items.

For example, on a bug, the Tester should be testing and associating test results and data with the build that is under test. When they create a bug Microsoft Test Manager automatically fills out the "Found in" feels with the build number.

This allows the coders go easily identify if the bug still exists or if this is an old report. The bug may have been fixed already, or this may be a regression. Or it may be just an old build deployed to QA.

Once the coders have fixed the bug they checkin (push) that change and associate it with the bug, they can choose "associate" or "resolves". Now when the CI, or Nightly (you choose) build kicks off it knows that the bug is included in the build and uses the build number to write onto the bug in the "Integrated In" field. Just to make sure the build system also walks the chain of parents and also writes to the "Integrated in" field.

Now you can easily query the system for any work items where the "Integrated In" field is less than or equil to the current build number and see all work, partial and complete, that is included in that build.

If you then progres to using the Release Management system as well it will pull on that data and allow you to know which builds, or versions of your software have been deployed to which environments.

So you can easily get get:

1. For a build exactly what work items are available for test
2. For an environment exactly what build of each component is deployed
3. Exactly which test cases (really each test point) has been run against which build.

These are all productivity enhancements that still require team discipline:

1. Coders need to focus and associate commits/checkins with the correct work items and choose "associate" or "resolve" appropriately
2. Testers need to select the correct build that they are executing their tests against

If you have any additional questions then I am happy to discuss...

Answer 2

Generally speaking, anybody can create a user story, but only one person or group of persons can prioritize the list of user stories.

I'm not familiar with SAFe but it is not that far from other Agile Frameworks, where the Product Owner or Project Manager creates the user stories. When the list is available, the tech leads, the team, the data folks, and the testers review it and change the content accordingly and suggest a possible place in the list. When they done with a subset, the responsible persons order the list.

I think it is good to have a status on the user stories. It helps the team and external testers to know which user stories are ready to be used or tested. However, if we are talking about your internal testers, then you won't need it. They must be part of the daily and weekly routine and therefore should know the status of the user stories. A "definition of done" checklist or document may be useful to you which helps to determine the status of a user story.