Work orders & User Stories

Work Orders

In software development, variation in work order size is high. To manage the variation, we control coupling and specify requirements by following a well defined schema that limits complexity. This schema is the user story.

User Stories

As a structured use case, a user story describes the value that the product delivers to the user or purchaser of a system, roughly by telling a story about how the product will be used.

They should say as much as possible about the user's needs, expectations, and goals, and as little as possible about the design of the product.

It’s emphasize verbal communication, should be understood equally by the customer and the developers and they encourage the deferring of detail.

To identify stories, start by considering the goals of each user role in using the system. Keep the user interface out of the stories for as long as possible.

A story may reference to, or be composed of other stories. 

Augment stories with functional requirements, other requirements gathering or documenting techniques as necessary for the project's domain and environment.

Size

To be a candidates to schedule for development, stories must be decomposed until they become atomic and of similar size. An atomic story is a Feature.

How to write them

A good story follow the INVEST pattern:

• Independent: They can be developed in any order. Dependencies lead to prioritization and planning problems. 
• Negotiable: They are not written contracts. When the level of details is too high, the solution is less flexible. 
• Valuable: To users or customers. 
• Estimable: Developers are able to estimate size or time to implement. 
• Small: If stories are too large, you cannot use them for planning. Instead, compound and complex stories may be split into multiple smaller stories. If they are too small, multiple tiny stories may be combined into one bigger story. When splitting a story, try to come up with stories that cut through all layers of the application. Write smaller stories for functionality the team will implement soon, and write broad, high-level stories for functionality further into the future. 
• Testable: So we know when it is completed. 

They are composed of three aspects:

1. Description: Use active voice. For example, say "A Job Seeker can post a resume" rather than "A resume can be posted by a Job Seeker". Write stories for a single user. Instead of "Job Seekers can remove resumes" write "A Job Seeker can remove her own resumes." 
2. Conversation notes: Flesh out the acceptance criteria. 
3. Acceptance criteria: Contain most of the details of the story

Acceptance criteria's

• Done before the programmer begins coding.
• Analysts should spend much of their time defining acceptance criteria. 
• Analyst work closely with testers and the customer to define acceptance criteria.
• Stop writing when additional criteria will not help clarify the details or intent of the story.
• By which we can judge if a particular requirement has been met. 
• Used to express details that result from workshop and conversations. 
• Traceable to customer satisfaction
• To be eventually converted in Gherkin scenarios with automation

Benefits

Ensure that every party to the implementation of a requirement has a good understanding of that requirement and of their role in its delivery.

This approach prevents overproduction waste:

• Analysts from creating “ivory tower” requirements that are expensive to implement or test. 
• Testers from raising defects that aren't defects but are instead a misunderstanding of the system. 
• Developers from implementing something that bears little relationship to what anyone really wants.