Skip to main content

Is this good user story?

Last post 06:31 pm January 11, 2022 by Ian Mitchell
10 replies
12:05 pm April 14, 2015

Hi,

Can someone please help me reviewing below user story?

As a parent, I would like to have my registration information which I have already entered previously on my account in form is pre-filled when I register an event, so that I can register quickly.


Acceptance criteria:

1.Parent click “Register Now” button for an event
2.In registration form, registration information which parent has already entered previously on his account in form is pre filled.
3.Parent click “conform” button to complete registration.


01:27 pm April 14, 2015

Jo,

User Stories are not part of a Scrum, but they are a good technique to use alongside Scrum.

There are things about a User Story that can't be told over the internet.
https://scrumcrazy.wordpress.com/2013/06/04/its-difficult-to-give-user-…

I'm not a huge fan of the "As a user..." template:
http://www.scrumcrazy.com/User+Story+Basics+-+What+is+a+User+Story%3F

One good way to assess your story is to assess it against this check list:
http://www.scrumcrazy.com/A+User+Story+Checklist

I would expect to see some more acceptance criteria around non blue sky scenarios and preconditions...
How does the system know which parent is signing up? (via a login?)
Is the data in the parent's profile perfectly transferrable to the registration -- or are their data translation issues?
Can the parent override that info? Should we verify that the overriding works?
What are all of the test cases that comfortably prove that this functionality works correctly?
(Note that it's not important to document every last test case -- just that there's a shared understanding about what those test cases are)

The Acceptance Criteria might be well represented using the "Given When Then" or "Specification By Example" patterns:
http://www.scrumcrazy.com/stp

Also, I'd want to know if the story represents something of high value to the stakeholders and meets the INVEST criteria:
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Be sure and see the links at the bottom of this page:
http://www.scrumcrazy.com/User+Story+Basics+-+What+is+a+User+Story%3F

Hope this helps!


01:35 pm April 14, 2015

Some of the links got mangled, let me try again...

There are things about a User Story that can't be told over the internet.
http://scrumcrazy.wordpress.com/2013/06/04/its-difficult-to-give-user-s…

I'm not a huge fan of the "As a user..." template:
http://scrumcrazy.com/userstories

Be sure and see the links at the bottom of this page:
http://scrumcrazy.com/userstories


12:47 pm January 3, 2022

I have a challenge. There are three teams which work on a story in different sprint. Example, Back end team, Front end (UI) team and Testing team. First back end teams completes there tasks in first sprint and UI team develops screen for that story in sprint 2 and connects the UI to the back end development which was done in Sprint1. In sprint 3, testing team takes the same story and starts testing it.

My challenge is, As a product owner, should I have to write same story three times for three teams? We cannot create three tasks, when we do that, the story will be in TODO for three sprints, which Back end team is in disagreement.

 

please suggest...


04:59 pm January 3, 2022

From what you arę describing @Prakash none of those teams seems to be cross functional and able to create Done Increment within a Sprint. What you described is rather waterfall / silo a’like approach backend phase (team) -> us phase (team) -> testing phase (team).

Maybe you should consider with those involved people how you could rearrange into cross-functional and as autonomy as possible teams that are able to create Done Increments in a Sprint with little to no external dependencies and without handovers to other teams?


06:11 pm January 3, 2022

My challenge is, As a product owner, should I have to write same story three times for three teams?

No it isn't. Your challenge is that no story you ever write can ever be ready for Sprint Planning, because no team can ever complete it in one Sprint. The cross-functionality isn't there. That's the issue you need to address. Until you have a team that can finish work each Sprint, and commit to doing so, you won't be able to account for value and optimize it.


11:51 am January 5, 2022

I repharse it. I am running 14 days sprint. Let us have two role players. Developer and Tester. The developer completes the story on 12th day of the sprint. The tester completes testing only on 14th day. The story gets carried forward to next sprint, since the test feedback is not yet completed by Developer.

 

How to avoid this? Should dev team plan such a way that all stories are completed in 10 days and reserve last 4 days for testing iterations, so that planned stories are done within sprint?

 

 

 

 

 


01:51 pm January 5, 2022

How to avoid this? Should dev team plan such a way that all stories are completed in 10 days and reserve last 4 days for testing iterations, so that planned stories are done within sprint?

Firstly, don't treat them as separate roles. They are both Developers whose work will be necessary for a Done increment that Sprint. As such, they ought to collaborate with a joint focus on the completion of individual stories, early and often.

Your proposal would involve the preservation of silos and the waterfalling of a Sprint. This might result in a finished increment within a Sprint timescale, but I'd suggest it's a poor risk control mechanism for doing so.


10:00 pm January 10, 2022

The developer completes the story on 12th day of the sprint. The tester completes testing only on 14th day. The story gets carried forward to next sprint

What jumped out to me in this statement is the size of the story.   Why is it taking most of the sprint to develop? 

I would work with the team on splitting strategies and crafting smaller stories.   Smaller stories improve sprint flow, support earlier testing engagement, and reduce the likelihood of carryover.



Without an explicit commitment to reduce story size, your team will continue treating sprints like mini-waterfalls.


02:38 pm January 11, 2022

How do you split a story into smaller stories? Does each "small story" needs to be fully "releasable"? Sometimes, you just can't break a story into something small and have them releasable by themselves.

For example, assuming there is no online payment system in place, "as a user, I want to pay purchase with my credit card". How do you split this into smaller stories that can be independently released?


06:31 pm January 11, 2022

How do you split a story into smaller stories? Does each "small story" needs to be fully "releasable"?

It's the increment that needs to be of this quality. If each user story makes sense as an increment in its own right, that's great. You'd then have multiple opportunities to exercise empirical process control. Scrum requires at least one increment be made usable, for that purpose, each and every Sprint.


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.