User Stories Best Practices

"As a [type of user], I want [some goal] so that [reason]."

When we create user stories for this build, we should consider the INVEST acronym created by Bill Wake.

Independent We want to be able to develop in any sequence.

Negotiable Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.

Valuable Users or customers get some value from the story.

Estimatable The team must be able to use them for planning.

Small Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.

Testable Document acceptance criteria, or the definition of done for the story, which lead to test cases.

Additional information to consider:

Strongly consider all parts of the story format The story format is intended to guide a discussion around the functionality. You define the perspective, the scenario, the goal, and the value. All of these are very important.

Try to take the customer perspective Whenever possible, try to write from the customer perspective. This gives us an easy way to see progress on the site and focus on stories that deliver functionality to the customer.

Try to focus on goals over implementation The story should frame a customer goal. Customers don't care how the backend implements a system, they care about the things they can see and do.

Link stories together The site is very complex. As we get more and more stories, linking them together provides a lot of context to the story writers and eventually the developers.

View the story from a non- developer perspective Ask yourself if you did not work at Business Wire and were asked to review the completed work, what would you be viewing? If you were a developer, what work would you be doing? If you were a code reviewer, how would you decide if the work met the needs of the story? Many of the stories are fairly open or rely on internal knowledge.

Build the functionality then aggregate it Many of these stories start from the end goal rather than building towards it. We can't complete "all" the styling for a page in most cases in a single story. We need the stories for all the components of the page. As those pieces are developed, they will come together into the end result. The general page often develops features over time, so trying to tackle it once for all is often difficult.

Some keywords to look for Avoid using "and" or "or" in stories. They indicate that the story is really about more than one thing. Avoid "all" or "fully". They indicate that the story represent one point in time that will often quickly become out-dated. Rather, list the specific instances for that time. We can add more later.

Examples of Tickets and Ticket formats

Front End User Story	Acceptance Criteria
As a [...USER ROLE...], I would like [...TICKET REQUIREMENT...] before [...ACTOIN...] So I can see [...REASON WHY...]	(/) Scenario 1 - Scenario Title Given I am a [...USER ROLE...] When I create a [...TICKET REQUIREMENT...] and[...ACTOIN...]Then I am taken [...DESIRED RESULT...]