Here is a revised version of Microsoft’s Agile User Story Work item Template (WIT) which I have adapted to permit greater flexibility in rejected the story. You can download it here http://2020fs.com/assets/TFSWITs/user%20story.xml
There is no warranty expressed or implied, it’s free for use and modification, but all I ask is that you credit it back to here with the appropriate links if you use it.
Enjoy.
User stories represent narrow verticals, typically one screen of user interface or a short user journey. Where a screen is reused but with different details (fields, workflow, purpose) according to alternate actors for example, more than one User Story will exist but they will have a “related” type relationship described.
Assigned To
This field holds the identity of the BA who is responsible for delivering the analysis (when the workflow status is any of New, In Analysis, Ready for Analysis Review by Client, Ready for Development) and of the developer who takes ownership of the implementation (when the workflow status is Ready for Development or any subsequent state). During testing, the owning developer is still named in this field to make it easier for the USER STORY to be returned should any part of the testing fail.
State
User Story WIT Workflow
This describes the present condition of progress of the USER STORY in the workflow (see diagram above).
| State is changed to | State set by | Trigger | Actor | Action |
| New | Analyst | New requirements are discovered | Analyst | User Story is created |
| In analysis | Analyst | Requirements are understood | Analyst | Business requirements documentation commences |
| Ready for analysis review by client | Analyst | Requirements are documented | Client Analyst | Client reviews business requirements documentation |
| Ready for development | Analyst | Client validates business requirements | PM, TDA, Tester | TDA estimates workload; PM allocates USER STORY to a phase; Tester commences describing behaviours; Unit test skeletons written |
| In development | PM | USER STORY is assigned to next/current phase | Developer | Implementation commences |
| Ready for testing | Development manager | Implementation is complete | Tester | USER STORY enters testers’ queue |
| In testing | Tester | Tester is available to test USER STORY | Tester | Testing commences |
| Testing passed by Supplier | Tester | USER STORY passes all behavioural tests; USER STORY meets exit criteria | Client Tester | Client reviews implementation |
| Testing passed by Client | Tester | Client validates implementation | ||
| Deprecated | Analyst | USER STORY is out of scope | ||
| Deleted | Analyst | USER STORY is mistakenly created |
- At any point, the analyst may remove the USER STORY either by marking it as Deprecated, when the USER STORY is out of scope, or as Deleted, when the USER STORY has been created in error. Although this action can be executed by any TFS user, it should only take place with the expressed agreement of the analyst.
- A User Story is created by the analyst when she is aware of its existence. All User Stories and requirements are to be captured regardless of their scope.
- Once the analyst begins work on understanding and document, she marks the USER STORY as In Analysis.
- When the analyst has completed the USER STORY, she marks it as Ready for Analysis Review by Client and then presents the USER STORY to the Client for review and validation.
- If the Client is not completely satisfied with the USER STORY, the analyst returns the state to In Analysis and makes the changes recommended by the Client.
- Once the Client has agreed that the USER STORY is correctly written, covering the expected business requirements comprehensively and without ambiguity, the analyst marks the USER STORY as Ready for Development.
- User Stories with a state of Ready for Development are reviewed by the technical design authority where implementation notes may be added to the Developer and Tester descriptions accordingly. If the TDA is not satisfied with the content of the business description, he may return the state back to New for further work by the BA, or he may amend the USER STORY and return it to Ready for Analysis Review. In either case, the USER STORY is assigned back to the BA.
- If the USER STORY meets with the satisfaction of the TDA, the project manager will decide in which phase the USER STORY belongs. A developer may or may not be assigned to the USER STORY at this point. If a developer is assigned, he becomes the owner of the implementation of the USER STORY, although that does not preclude other developers from performing some or all of the implementation.
- User Stories that are marked as Ready for Development can be reviewed by the tester who may now start describing the behaviours and writing test scripts for the USER STORY.
- Once a developer is ready to implement a User Story, he marks it as In Development. He may work alone on this USER STORY or he may wish to involve other developers. The owner is the developer assigned to the USER STORY and it is his responsibility to ensure it has been implemented satisfactorily with sufficient code coverage and meeting all of the requirements described in the USER STORY. Should the tester have already described behaviours, the developer owner should be satisfied that the implementation passes all tests described thus far.
- In the event that a developer is unable to implement the User Story due to incomplete analysis, he may return it to Ready for Analysis, flagging the reasons in the Notes or other sections as appropriate.
- When a User Story has been implemented to the satisfaction of the developer owner, he will notify the development manager who will mark it as Ready for Testing, at which point it joins the test queue. He should not change the Assigned To field.
- The tester shall frequently query to return User Stories marked as Ready for Testing. Once the tester is available to test the USER STORY, he moves it to In Testing but does not changed the Assigned To field.
- A tester may reject the analysis of the USER STORY and return it to In Analysis, setting the Assigned To field to the business analyst. This is expected to be an edge-case scenario and is unlikely to occur.
- Only when the Test Manager is satisfied that a User Story fully implements all of the behaviours described in the USER STORY and passes all tests should he mark it as Testing Passed by Supplier. Bugs may be raised against “passed” User Stories, typically regarding non-functional implementation detail or test automation.
- The tester is responsible for reporting to the Client that a User Story is believed by Supplier to be complete and ready for their review. All known associated Bugs should also be reported to the Client at this point.
- If the Client is unsatisfied with the User Story, she will ask the tester to return the USER STORY to the In Analysis state and assign it back to the business analyst.
- Where the Client is satisfied with the User Story but does not believe the implementation covers the behaviours described in the USER STORY, she will request that the Supplier tester returns the USER STORY to In Development.
- User Stories that are implemented to the satisfaction of the Client, only to the extent that they meet all of the described or implied behaviours, can be marked by the Supplier tester as Testing Passed by Client. Bugs which are not covered by the USER STORY, including failure to meet non-functional requirements, should not inhibit the USER STORY being passed by the Client.
Reason
Whenever the state of the User Story changes, the reason is used to describe the trigger for the change of state. Exclusively for User Stories, there is only one reason available per state transition and may be treated as a descriptor only.
Flags
This field is for free-form use by the project manager to mark User Stories to assist with creating queries and therefore should be ignored by all other TFS users.
Area
The Area field describes the high-level vertical association with the application.
Iteration
Iteration is used to identify in which release a User Story is expected to be implemented. This field should only be changed by the project manager or with the consent of the project manager.
Approved by, approved on
The Approved fields are used to record the acceptance of the business understanding and of the implementation of the User Story by the Client.
- When the state of the User Story changes from Ready for Analysis Review by Client to Ready for Development, the name of the business owner or her proxy should be set in the Approved By field by the Supplier business analyst. The time of the approval should be recorded in Approved On field at this point. The BA may also choose to add notes to the History field at this point also.
- Whenever the Business description field changes, the user must ensure that the Approved By and Approved On fields are set to blank [no value]. Like all changes to the work item, the previous values can be found in the History audit log.
- When the state of the User Story changes from Testing Passed by Supplier to Testing Passed by Client, the Supplier tester should set the name of the Client tester who has approved the implementation and the date and time at which approval was granted. The Supplier tester may also choose to add notes to the History field at this point also.
Approve before
This field is used exclusively by the project manager as a record of the deadline by which the Client must fulfil their responsibility to either review a User Story or the implementation of a User Story.
Stack rank
This field is used to describe the priority of a User Story and should be populated by the project manager, optionally with the assistance of the technical design authority, business analyst, tester and developers. Stack Rank should be a number, typically in the thousands, where the lowest numbers represent the highest priorities. Values as multiples of 1000 are normally applied to make it easier to insert priorities later on (e.g. Stack Rank 2500, 2750, 2800, etc.). Typically, this should take the form that the last three digits represent priority and the first one or two the phase. Phase 10 User Stories should default to 10500, phase 9 to 9500. The last three digits should be changed according to the place of the USER STORY in priority, the lower the number, the higher the priority.
Story points
The project manager shall work with the technical design authority to populate the high-level estimate of implementation, spread across the development team but typically excluding analysis and testing effort. This value is used for project planning purposes and is not related to task estimates and should be ignored by analysts, developers and testers.
Security risk
The technical design authority may populate this field with a perceived risk of security implications for consideration by developers. Developers may, with consent of the TDA, upgrade the security risk. Where security risk is raised, accompanying information may be present in the Developer Description, Tester Description and/or Notes fields.
Business description with acceptance criteria
All User Stories are described in terms of business requirements, represented as postcard User Stories in all new User Stories.
It is the responsibility of the business analyst to populate this field and to present it to the Client analyst/business owner until it has been approved by the Client. Whenever this field is changed, the Approved By and Approved Dates should be set to blank [no value] and the project manager should be made aware that the Approve By date may need updating. All parties (developers, tester, PM, TDA) must immediately receive communication from the BA that the USER STORY has been changed.
The content of this field fully and accurately describes the business requirements with relation to the USER STORY. Should any wording in the USER STORY conflict with understanding expressed elsewhere, such as an attached item, the Business Description should be considered correct.
Developer description
This memo field contains notes to aid development. These notes can be updated by the technical design authority, developers, business analyst or tester as they feel appropriate. The contents of this field may be changed during the phase without affecting the analysis approval state.
Tester description
This memo field contains notes to aid testing. These notes can be updated by the technical design authority, developers, business analyst or tester as they feel appropriate. The contents of this field may be changed during the phase without affecting the analysis approval state. Testers must be familiar with all elements of the User Stories, with special emphasis on the business description and tester description, and consider these when testing and raising Bugs.
20/20 Foresight 