Is this good user story?
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.
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!
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
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...
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?
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.
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?
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.
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.
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?
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.