Help with User story
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?
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.
Thank you Chris for your feedback.
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?
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
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!
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.