1. One Pager User Story
This method of capturing requirements, technical requirements, functional specifications
and testing methods not only serves the need for documentation. More importantly, this
process brings everyone together to understand the Why, What and How. This does not
only ensure everyone’s on the same page but is also conducive to instant buy-in from the
team which more often than not results to increase in productivity.
Instead of having the BA to write a 30+ page detailed design document where sections in
the document can become out of date by the time the last page is written, write One
Pager User Stories. Store the user stories in ServiceNow the same way BCAA does it
today.

2. Brief summary
User stories are short, simple descriptions of a
feature told from the perspective of the person
who desires the new capability, usually a user or
customer of the system. They typically follow a
simple template:
As a <type of user>, I want <some goal> so that
<some reason>.

3. Acceptance Criteria
Acceptance Criteria are the conditions that a software product must satisfy to be
accepted by a user, customer, or in the case of system level functionality, the
consuming system.
Acceptance Criteria are a set of statements, each with a clear pass/fail result, that
specify both functional and non-functional requirements, and are applicable at the
Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of
Done”, and by done I mean well done.
We’re not talking about horsheoes here, and there is no partial acceptance: either
the acceptance criteria is met or it is not.
Acceptance Criteria should state intent, but not a solution (e.g., “A user can approve
or reject an invoice” rather than “A user can click a checkbox to approve an invoice”).

4. Technical Approach
With 100% clarity on the acceptance criteria, the Dev team will now answer the
“How” in relation to the implementation strategy? This section should clearly
state how Dev proposes to implement the solution while considering the risks and
benefits. This section can and should state what is not included to better define
the scope and effort.
Example of a benefit would be being able to reuse an existing set of APIs built for
Product A (Web app) when building a new feature in Product B (mobile app).
Technical Approach should address the following concerns:
1) Technical Reviewer – technical viability and elegance
2) Project Manager – relative delivery risks and costs
3) Users/Managers – functionality, user experience, ease of use and training

5. Testing Approach
With 100% clarity on the acceptance criteria and technical approach, the QA
will answer the “How” in relation to how the solution is to be verified and
validated. Also, this section may answer the questions on how defects are to
be tracked and prioritized.
E.g.
1) Perform functionality, integration and system testing
2) Perform boundary testing, input validation and permission based testing
3) Perform back end and front end testing
4) Test lead will create a shared “Outstanding Issues” query on JIRA that will be
shared by all the stakeholders in this project
5) Project Manager will create and main Kanban board specifically for this project
6) Bug Triage is to be held once a week to review defects reported during the
current sprint

6. Without detailed functional/technical
specifications…

7. What the client expected

8. What Dev built

9. What QA tested for
OR
How will the BA feel if QA tested for #1?
How does testing for #2 affect the working relationship between Dev and QA?
Is QA really at fault for testing for #2?

10. Here’s an example
As an Agent, I would like to be able to endorse an active policy so I can add assets to the policy
Acceptance Criteria - By product owner
Select one city at a time using the location selector.
- Apply to page X and page Y
- The existing standalone drop down moves into the location selector.
- If viewing multiple cities, select the first city in the location selector.
- If there is a large number of cities, allow the selector to scroll.
- Ensure long city names can fit.
- For very long city names that will not fit the max width of the selector, display with ellipses.
- Default sort: city ascending, province ascending. Case insensitive.
Performance Acceptance Criteria - By product owner
* No performance degradation compared to how page X and page Y were before.
Not included in Acceptance Criteria - By product owner
- Prompt user before changing city when there are changes. etc.
Technical Approach - By Dev
- Section selector will be done as a new widget so it can be re-used in other pages.
- The Angular services that feed data into the location selector require changing.
- It's anticipated that there will be no back-end service change needed.
- The list of cities will be based on the logged in user.
Test Approach - By QA
- Dirty state checking
- Cities and sort order are correct
- Test tracking of selections
- Test with single and multi-city context
- Test around client side caching behavior moving between pages
Performance Test Approach - By QA
* Verify that you're only getting back one city at a time via the browser's network tab
* Test for no degradation compared to page prior to this change.