Story writing help
Hi All,
I'd like some help on Story Writing please. I will share my use case and then ask my questions.
Use Case
We need to create a very simple look-up service. A single API endpoint that takes a look_up_id in the payload and returns another single piece of data if the look_up_id is found in a DB search. The whole service needs to be built as a stand alone service outside of our test, dev and other environments. There is no auth required, the supporting DB will be populated with dummy data and there are no performance requirements.
Options for writing this up for Development to work on are:
Create an Epic
With User Story's for:
- User_Story_1 - API: Specification.
- User_Story_2 - INFRASTRUCTURE: Create stand alone service.
- User_Story_3 - DB: Create and populate with dummy data supplied.
Create a single User Story
With Acceptance Criteria for:
- API: Specification.
- INFRASTRUCTURE: Create stand alone service.
- DB: Create and populate with dummy data supplied.
Questions
- Should it be an Epic? - This whole piece of work will take no more than 1-2 days to complete. This does not fit with what an Epic is.
- Should it be a single User Story? - I read that there should be about 1-3 Acceptance criteria per a User Story. If this is one, there will be loads more than 3!
- Is there any other way I should be doing this?
- Is there like a single resource I should be using to get a steer on this? - There are 1,000's out there but none I can find that address my issues specifically.
Many thanks in advance for your help,
Cheers,
Paul
Why not take a look at the INVEST criteria which are widely recommended for user stories? How might this change your approach to authoring them?
@Ian's suggestion is a very good one. It has helped me and some of my teams on many occasions.
One piece of advice. Quit taking everything you read as rules. Look at them as opinions or suggestions (including everything I am typing right now). Do what makes sense for your team even if that differs from time-to-time. But don't err on some kind of "process" over practicality. If it takes you longer to write up the multiple items than it will take to do the actual work, you may be "doing it wrong". I'm going to point you to my favorite principle from the Agile Manifesto for Software Development.
Simplicity --- the art of maximizing the amount of work not done --- is essential
Ian, Daniel,
Thanks so much for your responses. Really interesting and valuable feedback, I shall take it on board.
Very much appreciated.
Cheers,
Paul