Agile Story Template
Story Business Status:
- This story has been discussed and vetted with key stakeholder(s) for completeness
- This is a draft story
requires stakeholder review for completeness
- This should describe the high
level business situation and players involved. Example: As a [role], I want to [action] so I can [outcome]. Identify the business impact if this requirement is not met operational execution, support, reporting/inspection, productivity, adoption, financial . Try to give examples of typical business scenarios.
evel equirements (grouped logically with key points identified: 1. ser/ roup, 2. process/action, and 3. vision)
- If applicable, list any constraints
: Include constraint items such as required hardware, required software, required third party software, etc. that the user must have to use the functionality in this business design. Include set up or usage constraints for implementing the new functionality included in the business design.
assumptions of how this functionality or process should or should not behave.
Conditions of Acceptance:
- Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to quash collaboration.
- Acceptance criteria answer the question
, “How will I know when I’m done with the story?” Test cases answer the questions , “How do I test and are the test steps?”
Level Test Case:
the test cases that will ensure results will meet expectations. This also will help the IT team as they may not think of all the possible business scenarios.
ps/Attachments eference these in the description so that people are aware of them dd to stories where relevant
Challenge 2: Timing and the Globally Distributed Team
We had numerous challenges in this area:
- Determining sprint length
- Aligning schedules for vacations, holidays, quarter-end moratoriums, etc.
- Globally distributed teams
- Incorporating integrated user acceptance testing
We started with two-week sprints but ran into the obstacles of holidays, moratoriums, story writing, team member availability, porting, and sprint planning activities. It became almost impossible to complete everything in a two-week timeframe and at the same time achieve a meaningful level of development.
Agile recommends collocation of the team; when this is not possible, a lot of timing obstacles arise that must be carefully addressed. In today’s world, many organizations do not have the luxury of putting everyone in the same room. Consequently, things like optimizing the lag time between time zones, ensuring timely responses to issues, and facilitating handoffs become more challenging.
Both projects wound up with three-week sprints. This allowed some flexibility when dealing with holidays, moratoriums, and other scheduling obstacles.
Testing is included in our story definition of done; this includes user acceptance testing (UAT), not just developer unit testing. And we’ve found there is a lot of value in performing thorough regression testing each sprint. In the Integrity project this is handled by both automated testing and manual testing by developers in the last couple of days of the sprint. This has recouped time later on in the reduction of defects found in shipped code. It also removes the need for formalized end-game UAT, as we are getting that input on a sprint-by-sprint basis.