Splitting stories for a forgotten password user journey

[KentuckySpur]

Hi guys,

Having trouble splitting the stories for a reset password user journey.

The full desired journey step-by-step:

1. Users can request a new password
2. User enters email
   
3. User enters User ID
   
4. User enters DOB
   
5. Form submission confirmation screen
   
6. User receives temp password and reset link
   
7. User clicks links 
8. User enters confirms temp password
9. User enters new desired password
10. User clicks submit
11. Password reset confirmation screen

There's also client and server side validation for each of the input fields.

It's worth noting that the work has been done on a legacy system for DESKTOP.. The requirement here is to use the updated APIs and make it mobile-integrated.

Any guidance appreciated.

Regards,

KS

[Ron Jeffries]

Hi ...

Try thinking about the acceptance tests for this requirement, rather than the flow. What are the tests, from easy to pass to hard? What are they from important down to unimportant?

Ron Jeffries

www.XProgramming.com

I have two cats, and a big house full of cat stuff. 

The cats fight and divide up the house, messing up their own lives. 

Nice work cats. 

Meow.

[KentuckySpur]

Hi Ron,

Thanks for the reply!

The acceptance criteria would be the :

- Form server and client side validation as mentioned

- The system generates the password reset email

- The system generates a confirmation when the passwords match

etc

But the problem I have is ordering these into granular stories..At its more granular, the initial story needs to include a form, generate an email and provide the a page for the reset.

You could argue that there is potential for a split without the email etc.. But we already have the APIs in place to generate all these things...

Thoughts?

KS

[David Grant]

Try to be more granular, and think of examples you'd use in your acceptance tests.

For example, it's often easier to start with a failing case, such as the server side validation fails for an invalid email, User ID or DOB (at least three cases).  Whilst this isn't exactly what you want the story to do, it should be included, and it also gets you closer to the "full" scenario.

Dave

[John Miller]

Can you get the team to help write stories? They may be able to help get stories granular enough for them. 

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Nick]

Hi guys,

I get that we can split by validation..

What I don't get is that, the happy path is one big giant path where
they user HAS to:
- fill in 3 fields of a form,
- submit it
- click the reset link in their email
- fill in 3 fields to reset it

So whether or not we tackle the validation before or after, the happy
path is huge.. Any tips on breaking that down?

Cheers,

KS

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Scrum Alliance - transforming the world of work." group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/scrumalliance/15QcG-j886g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Heitor Roriz Filho]

Hello Nick

Creating stories beginning with use case flows can be tricky as it does not help you to shift from a developer's perspective to a user's perspective. 

I usually think as "what I as the user would do?" and start writing and breking epics. I believe in you case what you are looking for is something like:

As a <role>

I need to change my password

As a <role>

I need to confirm my password

Probably the cost of the first story you implement will be higher than the second one. I hope this helps.

You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Heitor Roriz Filho, MSc, PMI-ACP, CST
Certified Scrum Trainer and Agile Coach
Massimus Consulting and Training

http://www.massimus.com

Rally Software partner

Twitter: @massimusct

Facebook: www.facebook.com/massimusct
Cel: +55 11 8256-2757 | skype: hroriz
Ph: +55 11 2246-2826 / Fax: +55 11 2246-2799

[Nick]

Hi Heitor,

Thanks for your input..

My problem is, I am trying to ensure my stories are INVEST-worthy..

Therefore your example of:

As a <role>
I need to change my password

Doesn't actually do anything without the "confirm password" step..

So they're not independently releasable...

Cheers,

Nick

[John Miller]

Think "potentially releasable "

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[Heitor Roriz Filho]

That's fine, Nick.  If your PO says one does not make sense without the other, that's what will happen: sometimes we can't achieve independence and we need to put both in the same Sprint being up to the team to determine which comes first (they can always mock parts of the code anyway).

Otherwise one is potentially shippable without the other.

[John Williams]

Hi,

I'm curious,  Is a Reset the only option?  Or can there be a Password Hint Reminder that can be displayed with a request?
Second?  Why DOB (other than the fact it's what you're using now)?
Thirdly, Password Reset Request.
Client has the option of Password Hint or Password Reset  (this is now 2 stories)
Story 1 . Password Hint - Displays a reminder in the system that the user has specified.
Story 2 - Password Reset (potential Epic)

• User requests a Password Reset - Enters User Name and Some type of Private data (In this case you've chosen DOB) clicks submit, form is sent to the system for validation and an email is generated with the needed information
• Needed Information - has now become it's own story with various acceptance criteria
  
• System Identifies Users existence and sends email to the currently registered Email address in the system  (This will most likely be the last step/story to e completed)

See if this idea can help you with what you're trying to do.

John

[Markus Gaertner]

Hi KS,

you consider technical slices through your story. Is there another way to split this up - from a business perspective, maybe?

Best

Markus

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

[Markus Gaertner]

A more elaborate answer from a DDD/BDD perspective.

What happens in your domain? Someone requests a password reset. This is the main action for your BDD scenario:

When a user requests a password reset

In this case, a domain event should fire in your system. What should happen then? What are the actions? The system shall issue a password reset confirmation link in an email:

Then the user should receive a password reset email

What does he do with that information then? Well, there is another domain event lurking in this system:

When the user resets his password (that he received in the confirmation email)

Then he is requested to change his password

What happens with the request for changing his password, oh, wait, another domain event?

When the user requests to change his password

Then the user is notified about that password change (maybe by email, maybe on web)

Now, we have the happy paths. What about variations in the second scenario? Oh, there are some password rules that need to be applied, let's write down some criteria for that, but that's maybe a technical test for our password validator, and nothing we need to deal here in our acceptance test.

Do you see possible splits in this story now?

Best

Markus

On Tue, Apr 8, 2014 at 2:54 PM, KentuckySpur <thedy...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Nick]

Hi John,

I like your ideas and they're all ideas we've raised. Unfortunately
we're constricted by resources and a back-end system provided by a 3rd
party. We're also not allowed to display p/w hints, from a legal POV.

So looking at your "Story 2" (epic), this is pretty much how I
suggested the break down go...

STORY 1:
- User requests a password reset
AC
- Enters email
- Enters username
- DOB
- If a record is found, system generates an email with a temporary password

STORY 2:
- User inputs invalid email
AC
- User email not found
- Account blocked
- Show error

STORY 3:
- Users username invalid
AC
- Username not found
- Show error

STORY 4:
- User clicks the reset link from their email after successfully
requesting a reset p/w link
AC
- Enters temporary password
- Enters new password
- Confirms new password

STORY 5:
- Temporary p/w incorrect
AC
- Enters incorrect temp password
- Show error
- Allow user to continue re-trying for 30 mins (e.g.)

STORY 6:
- User could not confirm their new password
AC
- Entered non-identical password
- Show error
- Allow user to continue re-trying for 30 mins (e.g.)

STORY 5:
- User changed password successfully
AC
- Show success message
- Redirect to homepage (e.g.)



Are we getting closer???????


KS

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Scrum Alliance - transforming the world of work." group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/scrumalliance/15QcG-j886g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[John Clifford]

The way I solve this problem is to remind myself that the 'I' in the INVENT acronym (thank to Mike Cohn) means independently implementable and verifiable... not independently deliverable. We need to divorce delivery from deployment; a single user story by itself may not have enough value to deploy to the customer even though we can validate it independently as potentially shippable (the underlying code will not have to be reworked or fixed before deployment).

So, you could break this up into three separate user stories... 'As a user I want to be able to have a confirmation email sent to me when I request my password be reset in order to ensure only I can reset my password' (user-request confirmation email), 'As a user I want to be able to enter a new password in order to ensure only I know what my password is' (user-enter new password), and 'As a user I want to confirm my new password in order to ensure it is set correctly' (user-confirm password). (I teach using the 'role-capability' verb phrase as a short description of the user story for brevity's sake, and as with a user story these should be unique to a particular product backlog.)

Each of those three stories can be implemented independently, and in whatever order... but the feature won't work until all three stories are implemented. Each should also be well within the capability of a typical Scrum team of 5 to 9 devs and testers to implement within a 2-week sprint, given the APIs already exist.

 - John Clifford

www.construx.com

[John Clifford]

Oh... the steps given would make a good start for a list of acceptance criteria for each story... noting that tests are just another form of requirements.