Skip to main content

Help with User story

Last post 03:28 pm September 26, 2022 by Daniel Wilhite
6 replies
12:17 am September 24, 2022

Hi, im new in the rol of PO of my organization and i would like some advise on a user story creation

So we want to implement a simple system that will generate a QR for our customers so they can use it to receive payments.

I have a user story of "User can Generate QR" which consist of a user filling in a form with about 10 fields, which will be validated and send to a service they have to create to generate the QR". After discussing it with the team, they say that probably due to the validations of the fieldd against some legacy systems it might take more than a sprint to complete the whole story as it is... 

I was thinking in splitting it maybe on "User can input required fields to generate QR" so they can do all the validation of the field and another of "User can generate the QR" for the service that will generate it  ... but its a part of the functionality and wont be even potentially releasable until its complete ... any ideas and suggestions on how to split it better?

 


01:49 am September 24, 2022

It's usually a good approach to split your stories (aka Product Backlog items) vertically (through the tech stack) so that the work is transparent by the end of the Sprint. The teams I work with would complete part of the form with the associated service work in one Sprint, then the final pieces of the form and service components in the next Sprint. Each Sprint produced a potentially releasable Increment (PBIs met the Definition of Done), but the Increment wasn't released in Production until the entire form and associated services were Done.

The downside of splitting work horizontally by doing the UI work in one Sprint and then the service work in another is that the Developers might find integration challenges too late in the following Sprint.


02:49 am September 24, 2022

Thank you Chris for your feedback. 


04:48 am September 24, 2022

I have a user story of "User can Generate QR" which consist of a user filling in a form with about 10 fields, which will be validated and send to a service they have to create to generate the QR"

I don't think you have. It sounds more like you've got a prescriptive requirement.

Scrum is not a reductive exercise of breaking such requirements down into chunks which are then somehow completed within "Sprints". Scrum is about using empiricism and learning experientially to build the right thing at the right time.

What is the smallest experiment you can run in a Sprint which validates those hypothesized QR requirements with the user, and not just a back end?


03:31 pm September 24, 2022

What is the smallest experiment you can run in a Sprint which validates those hypothesized QR requirements with the user, and not just a back end?

 Ohhh i see what you mean, and we can totally validate the QR generation hypothesis with just the critical fields.  Thank you very much Ian  


03:18 pm September 25, 2022

Dear Dereck,

Filling in a form of 10 fields...that seems like you are organising for a huge % of page abandonment. I would start with design and user interface. Courage and commitment are important values of Scrum. So challenge the 10 fields and use client input on the new form. Then go back to your legacy systems to see how you can best interact. Legacy systems often are an excuse to accept mediocracy. Split the work to get the most valuable outcomes!


03:28 pm September 26, 2022

I would suggest that you ask the Developers how to best split the story into units that can be worked within Sprints.  After all, they will do the work so who best can do that?  Work with them on creating the stories to create items that will produce functional increments. 

There is nothing in the Scrum Guide that says the Product Owner has to create all of the Product Backlog Items.  This statement is something that many people forget or never knew, if they have not read the Guide.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

Also, the activity of breaking these stories down is refinement.  From the Guide.

 Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.


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.