Writing user stories for website relaunch
Hi - can you help.
I am fairly new to scrum and my product owner is brand new to it. She owns this project which is to launch a refreshed website on a different platform making it easier to maintain etc, it will also encompass making the website mobile responsive.
She has started writing User Stories but I have a feeling they are more acceptance criteria. Things like 'as a customer I want to be told what else I might need - email/web hosting so that I buy everything from one place and feel reassured that I have everything I need' and 'as an editor I want to easily update list of domains so that the page always looks up-to-date'.
How should I advise her in writing good user stories that the dev team can use for estimating?
TIA, Mel.
Does she write the User-stories just on her own side ?
User-story = 3C's = Card + CONVERSATION + Confirmation
And user-story is litteraly a description of what the user is doing with your product, so the "I want to easily update my list" sound odd to me.
Yes, she is putting the backlog together but I'm trying to help make it meaningful. I've explained that the user story has to be a well defined piece of functionality or feature that the dev team can pick up and plan, it needs to be discrete and potentially shippable. I think if she used each page as a user story that would work? i.e. as a user I want the homepage to be easily readable and informative and enable me to navigate easily to the products that I want. The acceptance criteria would be a beautifully designed page with CTAs that are easily found etc etc. (She has said that she thinks design needs to be part of the user stories and as part of the delivery team because we're not just delivering a new application or software but something that looks beautiful.
I think that fact it needs to look good is something that is inherent and should be part of the acceptance criteria which is just as much part of the user story as a whole?
Hi,
I'm also new to scrum, so my post reflects my understanding of user stories and i welcome any advice or correction.
I think that the user story format is ok (at least as described on wiki), but the content is a bit "emotional" .
in my opinion, a user story must be more concise and should go straight to the point.
" as a customer I want to be told what else I might need - email/web hosting so that I buy everything from one place and feel reassured that I have everything I need " Seems a little too long. With a little grooming it would look like this :
" as a customer I want to be told what else I might need so that I buy everything from one place.
The core idea is present and the purpose is clear. No need to describe the customer feelings.
'as an editor I want to easily update list of domains so that the page always looks up-to-date' could look like :
'as an editor I want to update the list of domains'
Personally I like to enrich user stories with use cases because they bring more details to requirements.
The acceptance criteria would be a beautifully designed page with CTAs that are easily found
As a developer, I won't buy it !
How can I know if a page is beautiful ? Are your developers fashion victims ;-)
How can I know if CTAs are easily found ? (sorry, I don't what is CTA)
Maybe you can try some workshop for "Specification by example". What is beautifull to her ? What is easily found to her that your developer can use as acceptance criteria and test scenario ?
Lol Olivier! I know, she is very passionate and wants this amazing looking website and I agree with her, but trying to make her understand that this is subjective and doesn't really help the team is difficult! I think I'm going to go with each page. Eg. As Product Owner I want a Homepage that complies with business agreed branding, that has functional Call To Action buttons etc etc and do this for each page? The acceptance criteria would then be all these things that the Product Owner wants - refreshed look and feel based on re-designed graphics etc etc.
> The acceptance criteria would then be all these things that the Product Owner
> wants - refreshed look and feel based on re-designed graphics etc etc.
Have you tried using "Given...Where...Then" clauses? That should help provide some focus.
Sounds like your team might need some education and/or training on User Stories. I provide this training but I'm not here to sell my services. If you're interested you can contact me via ScrumCrazy.com.
Here are some good articles on the subject to get started with:
http://ScrumCrazy.com/userstories
http://ScrumCrazy.com/stp
My rule of thumb is: if user story makes your life more difficult, use other format that makes more sense.
Agility should serve the business, not the other way around.
Hi Mel
Actually I think you have the makings of a superb Product Owner here and you can certainly coach her towards that.
Chiming with a previous responder, the shortened versions might be (I've numbered them for reference):
1. "as a customer I want to be told what else I might need so that I buy everything from one place and am reassured I have everything I need"
2. "as an editor I want to update the list of domains so I can ensure the page is always up-to-date"
1 is absolutely an Epic and needs breaking down, maybe by page as you mention. This is a great way of working - starting with an Epic then breaking it down as it becomes higher priority - No need to yet break down Epics if they are way down the product backlog order.
Then acceptance criteria need adding to each resultant user story - For the subjective areas you might have "the following people [or roles] must score this page [assuming we're down at page level] at least a 4 out of 6 across each of the items on the attached survey" - Then work with your Product Owner to have her create a [one side] survey for all the subjective areas of a page.
The other thing I'd say about 1 is I'm concerned about "customer" - do you really only have just one type of customer or does this user role need breaking down? That said, even if you do decide you do have several types you might still decide you can represent them all in the case of this particular user story - Either way do think about it and make the explicit decisions - "User Stories Applied by Mike Cohn is a good book for this - it's written pre the As a <> I want <> so that construct but don't be put off by that.
2 might be a user story already or might be an Epic - I'd need to know more about your domain to decide. - Either way you need to explicitly work with your product owner and decide, then add acceptance criteria.
Do keep acceptance criteria as items added to the user story itself rather than trying to wrap them all up in the user story statement.
Hope that helps
Cheers
Jem
Thanks Jem, she is very passionate and very willing to do what needs to be done.
I agree entirely that acceptance criteria need to be separated from the user story 'statement'.
I think I have a good way forward with all this great advice, thanks all!
I think if she used each page as a user story that would work? i.e. as a user I want the homepage to be easily readable and informative and enable me to navigate easily to the products that I want.