Photo by Jamie Street on Unsplash (Edited badly, by me)

Writing a user story

A story about how we as developers try and understand and implement what our users need

One of our main responsibilities as developers is to write new feature that our users will hopefully enjoy. These features can come from any number of sources:

  • Our project partners
  • Ourselves
# As a user I do not want to have to re-enter my address.This is a story ticket! It contains broad information about the task, but no specific technical implementation details. For that, please create a subtask ticket, and do the work.## Project ManagerTo have this work marked complete users will not have to re-enter their address during the checkout phase.
It’s expected to have an increase in checkout conversion, which we will be able to see in the conversation metric in Google Analytics.
The due date on this work is 2018-01-01## DeveloperThis work is expected to take approximately 10. This has a Medium confidence. This will be implemented by adding the required autocomplete tags, such that the users browser will autocomplete their address. This should stay up to date, and reuse information the user has provided to other services but the browser has cached.## QAThe environment in which this can be tested is at the URL:https://path.to.testing.machine/Please see any QA tickets for additional context.

Title

As a user I do not want to have to re-enter my address.

Explanation

This is a story ticket! It contains broad information about the task, but no specific technical implementation details. For that, please create a subtask ticket, and do the work.

Story

## Project ManagerTo have this work marked complete users will not have to re-enter their address during the checkout phase.
It’s expected to have an increase in checkout conversion, which we will be able to see in the conversation metric in Google Analytics.
The due date where required is noted in the “due date” field.

It’s specific about the desired outcome, but not the implementation

Each developer will have their own specific way of solving the problem. Additionally, other stakeholders wish to convey their notions on how to solve the problem such that it meets their expectation and beaves in a way they’re able to predict. It is super important to convey the the proposed solution as soon as it’s known, but it should come either from or in partnership with the developer that will eventually implement the work. Otherwise, the solution might be agreed but impossible!

  1. Using the autocomplete APIs and address information already stored in the browser to fill in the address fields
  2. Avoiding the checkout completely with something like the PaymentRequest API
The user should have their address saved during checkout

It clearly indicates what will be used as the definition for a successful ticket

To have this work marked complete users will not have to re-enter their address during the checkout phase.
As a user I do not want to have to re-enter my address.
  1. Fill in their address
  2. Save their address
  3. Complete the checkout
  4. Complete subsequent checkout without entering address

It defines a measurable goal that can be checked to determine if the work functions as expected

It’s expected to have an increase in checkout conversion, which we will be able to see in the conversation metric in Google Analytics.

It communicates due dates for prioritisation

The due date on this work is 2018-01-01

Development

Indeed, the obligations to write clear user stories do not end with the project managers! We as the development team need to build on top of our work to clearly communicate our intent and manage the expectations of other stakeholders.

Estimation

This work is expected to take approximately 10 days. This has a Medium confidence.

Design

This will be implemented by adding the required autocomplete tags, such that the users browser will autocomplete their address. This should stay up to date, and reuse information the user has provided to other services but the browser has cached.

Quality Assurance

## QAThe environment in which this can be tested is at the URL:https://path.to.testing.machine/Please see any QA tickets for additional context.
  1. To ensure the ticket requirements themselves make sense
  2. To ensure that this work doesn’t degrade other aspects of the experience in arbitrary ways, not factored by this ticket.

In Conclusion

Writing an effective user story gives all stakeholders a clear idea about their responsibilities, the outcome and predicted life cycle of the ticket and when the ticket is expected to be delivered. It can prevent days of labour under false assumptions and kill many “misfeatures” before they’re ever implemented. It is a skill that is worth pursuing, and I hope that the above has at least made the development perspective on such tasks much clearer.

Additional Reading