Transitioning From Quality to Product Management — pt 3

User Stories can either save you or condemn you.

User Story

Acceptance Criteria

Acceptance Tests

  1. NEGOTIABLE
    Stories are not written contracts, they are reminders to talk to the customer. They are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team.
  2. VALUABLE FOR USERS/CUSTOMERS
    Stories should be written so that their value to users or customer is clear. To ensure each story is valuable to users/customers have the customer write the stories.
  3. ESTIMABLE
    The larger the story, the harder it is to estimate it. Developers need to be able to estimate the size of the story or the amount of time it will take to turn a story into working code.
  4. SMALL
    Size matters because if stories are too large or too small you cannot use them in planning. The user story is appropriately sized based on the team, its capabilities, and the technologies in use but also small enough to fit in a Sprint.
  5. TESTABLE
    Successfully passing the story’s tests proves that it has been successfully implemented.
User Story Elaboration (grayed fields are an alternative approach)

Definition of Ready

Definition of Done

In an Agile Scrum Framework — Where does DoR and DoD take place? / Artemisa Yescas 2020

Multiple Users

When writing a user story keep in mind to think about your user, a clearly defined role. if there are multiple end-users you could consider making multiple stories. User Personas is a method that helps to scope out the range of users, it supports writing user stories from the user persona’s point of view. Its impact is discovering the right stories.

Splitting Stories

Large user stories are actually Epics and they are further divided to form smaller stories. If a story doesn’t fit in an iteration, the story needs to split into two or more smaller stories.

  • Small pieces of work promote ownership and accountability by the team
  • The tasks are more doable
  • It is effortless to uncover key risks early on
User Story Splitting Patterns — Israel Alcázar 2014

Estimating Stories

Estimation is hard in the beginning. What is the right size of a story? There is no standardized or universal size for a user story, it always depends on your team, their skills, the technology in use, and their level of domain knowledge. Same as with splitting, when your team has a cadence, this will be easier and more accurate. The decision on which technique to use to point stories relies on you and your team.

Estimating complexity using Fibonacci Sequence — Artemisa Yescas 2020

Ok but, why User Stories?

  • It is an easy-to-understand concept.
  • Right size for planning.
  • Work for iterative development.
  • Emphasize verbal rather than written communication.
  • A placeholder for further discussions.
  • Reduce waste since nothing is done with the user story until it is prioritized by the customer.

Finally, some things to consider:

  • The difference between a user story and a traditional requirement is the level of detail.
  • Avoid the how trap. Acceptance Criteria states intent but is not a solution.
  • Do not write User Stories that require the development of other features.
  • Acceptance criteria need to have a standard of measurement used to gauge the progress of product development.
  • Effective User Stories should not exist without tight collaboration with the user and without them understanding what the requirement will supply.
  • Do not feel pushed to use User Stories, if this format doesn’t work for you there are other ways to do it.
  • Take a story writing workshop-helpful to figure out how to improve the product backlog and to fill it more effectively.

Next steps in part IV…

The advice other awesome PM/POs gave to me.

PMPO / QA at @EncoraInc | Practitioner in Agile Quality trainer | Coffee addict 🇭🇳 🇲🇽 ✨ she/her