Need some help for writing good user stories

[Benjamin]

Hi all !

My name is Benjamin, first time on a Google Group (woot !) and I'm trying to promote the use of SCRUm, Agile method (mainly) and the writing of user stories every time I can when working with dev teams.

I'm not SCRUM certified, more like a product owner who writes workflows, business cases and try to transform it into user stories

While I'm definitely convinced with working on small iterations, I have difficulties of writing good user stories and have some questions about it.

I'm using JIRA platform for projects now and usually we have multiple roles inside the app.

For example, we have roles like admin, director, secretary, client, etc

Directors can see the list of clients, details but the secretary and admin too.

One differences Secretary won't be able to view some part of the client information

So I've started to write user stories like this

"As a director I can see the list of clients"

"As a secretary, I can see the list of clients"

"As an admin, I can see the list of clients"

But also some stories like "As a director, I can log into the application", "As a secretary, I can log into the application" so a login form will be created.

then I put description inside the story and then regroup on EPIC like "Login" or "Client management", etc

Do I need to split stories for each role even if the view looks the same ?  It makes sense to me but in the other and I could have wrote "As a director or secretary, I can view the list of clients" since all functionalities on this view are the same for both of them..

Also for login it looks weird to have 3 same stories for the same functionnality (login)

I'm kind of confused on this...

Thank for answering me

[Henri Kivioja]

Hi,

I would first advice NOT writing user stories. They are named stories for a reason. That is to promote discussion and collaboration -> gain commonly understading  about business value to be delivered. 

BR

-Henri

--
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 https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Dinesh Sharma]

I suggest you read this article (https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/) to give you bit more insight into user stories. 

Thanks

Dinesh 

Hi,

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

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

--

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 scrumalliance+unsubscribe@googlegroups.com.

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

--

Many Thanks,
Dinesh Sharma

[Mike Abugow]

Hi there, so what I would suggest along with reading the suggested Ron Jeffries post below, you might want to consider adding Acceptance Criteria to your user stories to further narrow scope and define what each type of user role/persona sees and does in the application.  Using Acceptance Criteria aside from narrowing scope, helps teams and Product Owners know when stories are "done."  As for which style of Acceptance Criteria, there are several, and I find that what works for me and the teams I coach may not work for everybody.  We use a Behavior Driven Development approach.

[Mark Levison]

the comment from Henri is key. This article I wrote a few years ago: https://scrumalliance.org/why-scrum/agile-atlas/agile-atlas-common-practices/planning/october-2014/user-stories captures the same point in more detail. The formatting is poor. I will eventually get it fixed.

Cheers

Mark

Hi,

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

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

--

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 scrumalliance+unsubscribe@googlegroups.com.

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

--

Mark Levison | 1 (877) 248-8277 | Twitter | LinkedIn | Facebook Certified ScrumMaster Training: Vancouver | Edmonton | Ottawa | Montreal | Toronto Certified Product Owner & Private Training also available ~ Our Training Schedule Agile Pain Relief Consulting | Notes from a Tool User Proud Sponsor of Agile Tour Gatineau Ottawa and Agile Coach Camp Canada

[Pierre Neis]

Hmmm, stories are micro-narratives. Micro-narratives are delivering more informations than requirements expressing context, intention. The power of an user story is to put the user as key. What happens in the real world? People are just decomposing requirements into smaller pieces (stories) in a very traditional work breakdown structure manner. This is obviously totally wrong and an alteration of the intention.

Now, much better than stories are pictures. Drawing brings another level of clarity.

Like in Henri´s example, you just have a conversation without validation on the agreement, then you surely facing strong misalignment. That’s fine in research-and-development but totally wrong if you are expecting to delivering a tangible solution incrementally (delivery is the conversation with customers, users and management).

Now, regards to the initial question, to write good user stories you need:

- to know your user(s)

- to have a clear vision

- to ask them what they need towards that vision

- to let them talk

- to let the team attend that meeting to understand « the hidden » (what users are not saying but needing)

What not to do?

- gathering requirements like a Business Analyst without « meeting » the user(s)

- not working with the development team

But that’s what you should learn in a Product Owner training.

	Pierre Neis Senior Agile Coach | CEO agile2 GmbH p: +49 (0)160 998 724 49 m: +352 661 727 867 a: Wilhelmstr. 4, 69115 Heidelberg - Germany w: www.agilesqr.com e: pierr...@agilesqr.com
agilize everything

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

[Juan Pablo Botero]

Hi.

In my case i teached the people(users) to write the user stories, they said they like it the format and the way they participate in the definition of the product from their vision.

The truth is they never wrote the stories, so, we wait two o more days to obtain nothing was a waste of time, so we use other methods to get the "requeriments" from the users.

Maybe your case is different and you really get information from the users.

Also, further reading of user stories is a good idea before you show the users how to do the stories, the idea is that you can get the vision of the users and the stories obtained have sense to you and the team.

Cordialmente:
Juan Pablo Botero

[Benjamin]

Hi !

Ok understood but when you want to explain and write down in details how the app should work for the dev, what the roles can do or not, you just write down by functionnalities or you take your muser stories

I usually, do a quick wireframing of screens associated to user stories (As a xxx I want to xxx so I xxx) and a text explaining how user should interact and what results are shown.

I use JIRA btw.

Thanks

[Mark Levison]

On Wed, Nov 1, 2017 at 4:07 AM, Benjamin <benjamin...@ankaroo.com> wrote:

Hi !

Ok understood but when you want to explain and write down in details how the app should work for the dev, what the roles can do or not, you just write down by functionnalities or you take your muser stories

​Please recheck the Scrum Guide. Scrum recognizes no roles within the deve​lopment team. So there shouldn’t need to be role based items.

I usually, do a quick wireframing of screens associated to user stories (As a xxx I want to xxx so I xxx) and a text explaining how user should interact and what results are shown.

I use JIRA btw.

​JIRA has no bearing on how a team works. JIRA is a tool, the Agile Manifesto reminds us: Individuals and Interactions over Processes and Tools.

Cheers

Mark​

[Henri Kivioja]

Hi,

You got plenty of good advice but to me it looks you are not taking it seriously. I still recommend to forget your original question: if you aim to WRITE some user stories, instructions, requirements or whatever to another person or group of persons you miss the whole point. Please think about this and try to formulate together with your surroundings a good way to collaboratively find business and user value and also a way to have a method for organizing and keeping track where you are aiming. 

Once more: UserStory is a tool as is JIRA and the aim is to interact, collaborate and get a common understanding where your group is heading and sometimes even build that. 

BR

-Henri

--
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.