Skip to main content

Story writing help

Last post 03:14 pm May 23, 2019 by paul batty
3 replies
03:40 pm May 22, 2019

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

  1. 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.
  2. 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!
  3. Is there any other way I should be doing this? 
  4. 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


04:09 pm May 22, 2019

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?


05:32 pm May 22, 2019

@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


12:15 pm May 23, 2019

Ian, Daniel,

 

Thanks so much for your responses. Really interesting and valuable feedback, I shall take it on board.

 

Very much appreciated.

Cheers,

Paul


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.