[Cucumber] How to make Front End Developers read "User Stories" writtent in "3 Amigos Session" - Need Input

[80Vikram]

Dear BDD warriors,

I am following BDD since last 2 years & in current project we follow scrum/
agile with dedicated Agile Coach / Scrum master.


The process we follow is as below


*Before Sprint *

- PM writes acceptance criteria against multiple JIRA tickets relate to a
big feature

- As QA I write detailed user stories ( Gherkin Syntax ) as acceptance
criteria are quite abstract and lead to confusion, bugs

- I conduct "3 Amigos Session" with Dev ( Front End only ) & PM to
review, clarify and sign off user stories ( I do step 2 as my team thinks
writing stories together will waste their time, they are doing BDD first
time in their life )

- After "3 Amigos Session" both PM and Dev engineers appreciated and
liked detailed user stories in Given When Then format as it made things
pretty clear to them



*During Sprint*

- Daily standup to update to team how is work is getting progressed


*Post Sprint *

- Now the fun part starts, after sprint is over; I asked the same
developers again if they've referred to these user stories and answer was
BIG NO

- They have simply used design attached to ticket to write front end code
and told me that going through stories takes lot of their time

- One of the developer told me that he would have preferred if stories are
linked to design somehow ( we've design in invision app )





*My Queries to community ?*- During "3 Amigos Session" we had agreed that
developer will create sub-task based on user stories but they've created
based on design / screens

- How do you make your developer stick to user stories during development
or make them read it during development ?

- Or user stories are just for QA team in the end ( for doing manual
testing and writing automation with cucumber tool ) ?

- If you as well follow Agile / Scrum with BDD, please share your best
practices


Thanks in advance.

Regards,
Vikram

[Andrew Premdas]

It seems your developers have no stake in the Gherkin you have written.
There could be a number of reasons for this. Some things I noticed from the
language you've used

"You write detailed user stories, as acceptance criteria are quite abstract
and lead to confusion"

This suggests to me that some of the following might be true

1. You don't trust your developers much. It seems you are trying to
control/constrain your developers with your Gherkin
2. You probably don't iterate that much with your developers. You expect to
tell them HOW to do something and then have them do what you want them to
do.
3. You write verbose Gherkin

Your developers say that 'going through stories takes lot of their time'

This suggests that

1. Your stories aren't useful to the developers, the benefits they get from
them don't justify the time it takes to read them
2. They are time pressured
3. Your Gherkin isn't good enough, its probably far to long and full of
detail
4. Implementing your Gherkin is probably quite difficult

You say 'how do you make your developer stick to user stories during
development'

This suggests that

1. You believe your user story is something that you should stick to, i.e.
that you have learnt all there is to lean about the topic and that its just
the developers job to do what they are told.


If you want your developers to read your stories you should

1) Make them simple and useful.
2) Ensure they only talk about what needs to be done and why its important.
Give your developers more responsibility to determine HOW things should be
done
3) Allow you developers to challenge your stories
4) Realize much less is known about about that needs to be done when a
story is written than when a story is implemented, and treat the stories as
guidelines not instructions.
5) Give you developers more time (in particular allow them to start things
earlier)


Your presenting your developers with two artifacts, a picture and a story.
They are giving you clear feedback that the picture is useful and the story
isn't. You see that as a problem with your developers. Its much more likely
its a problem with your stories!

Most developers (in my experience) are time pressured to deliver alot of
functionality in a short period of time, and in particular to do what they
are told. BDD doesn't work for developers working under those conditions.

BDD is an agile process it only works of people realize that the process is
not about instruction but its about collaboration. Have 3 amigos get
together to produce instructions that the developers are then supposed to
deliver is not agile its waterfall and it really doesn't work. The amigos
should be working to produce guidance which is all about telling the
developers WHY something is important, and WHAT that something is, and then
getting them to start work on that before anyone has decided HOW things
should be done and before the UI has been designed. The whole point is to
get a minimal viable implementation early and then iterate having
stakeholders interacting and providing feedback so everyone communicates
and learns as the functionality is being developed.

Many many organizations think that having a scrum master and doing sprints
is Agile. Scrum can be agile but most of the time it isn't, its just mini
waterfall, or rushed waterfall or some other bastardization of waterfall. I
strongly suspect thats what is happening in your organization from what you
have written, and that is why your development process is not working as
well as you'd like.

Hope thats useful

All best

Andrew

Post by 80Vikram
Dear BDD warriors,
I am following BDD since last 2 years & in current project we follow
scrum/ agile with dedicated Agile Coach / Scrum master.
The process we follow is as below
*Before Sprint *
- PM writes acceptance criteria against multiple JIRA tickets relate to
a big feature
- As QA I write detailed user stories ( Gherkin Syntax ) as acceptance
criteria are quite abstract and lead to confusion, bugs
- I conduct "3 Amigos Session" with Dev ( Front End only ) & PM to
review, clarify and sign off user stories ( I do step 2 as my team thinks
writing stories together will waste their time, they are doing BDD first
time in their life )
- After "3 Amigos Session" both PM and Dev engineers appreciated and
liked detailed user stories in Given When Then format as it made things
pretty clear to them
*During Sprint*
- Daily standup to update to team how is work is getting progressed
*Post Sprint *
- Now the fun part starts, after sprint is over; I asked the same
developers again if they've referred to these user stories and answer was
BIG NO
- They have simply used design attached to ticket to write front end code
and told me that going through stories takes lot of their time
- One of the developer told me that he would have preferred if stories
are linked to design somehow ( we've design in invision app )
*My Queries to community ?*- During "3 Amigos Session" we had agreed that
developer will create sub-task based on user stories but they've created
based on design / screens
- How do you make your developer stick to user stories during development
or make them read it during development ?
- Or user stories are just for QA team in the end ( for doing manual
testing and writing automation with cucumber tool ) ?
- If you as well follow Agile / Scrum with BDD, please share your best
practices
Thanks in advance.
Regards,
Vikram
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org

[80Vikram]

Hi Andrew,

Thanks for your inputs, please find below answers

This suggests to me that some of the following might be true

Post by Andrew Premdas
1. You don't trust your developers much. It seems you are trying to
control/constrain your developers with your Gherkin
2. You probably don't iterate that much with your developers. You expect
to tell them HOW to do something and then have them do what you want them
to do.

3. You write verbose Gherkin
[Vikram] - I'm last one in the food chain just trying to push BDD to people
who never heard of it in their entire IT life.

Before I joined here; developer use to read "acceptance
criteria" written by PM ( which are not as descriptive to make things
crystal clear )

I write user stories and have "3 Amigos Session" where
developers have all the freedom to question each of the story and ask more
questions about unknown Rules & concrete examples.

This way we all end up writing new stories / editing existing
once.

Thus we're somehow *collaborating* *before single line of
code is written.*

Now the next challenge I need to solve is during development, asking
developers to stick to agreed upon *"User Stories". *

As they are not used to "User Stories" they simply looking into designs
linked to ticket. It's like going to Church and not reciting bible but they
own prayers.


? Do you also follow Agile

? Are you work as QA or Dev

? We waste few hours of team each week doing Grooming session,
Retrospective session and then I demand for "3 Amigos" session. Do you have
suggestion how to use time effectively

Thanks & Regards,
Vikram

Post by Andrew Premdas
It seems your developers have no stake in the Gherkin you have written.
There could be a number of reasons for this. Some things I noticed from the
language you've used
"You write detailed user stories, as acceptance criteria are quite
abstract and lead to confusion"
This suggests to me that some of the following might be true
1. You don't trust your developers much. It seems you are trying to
control/constrain your developers with your Gherkin
2. You probably don't iterate that much with your developers. You expect
to tell them HOW to do something and then have them do what you want them
to do.
3. You write verbose Gherkin
Your developers say that 'going through stories takes lot of their time'
This suggests that
1. Your stories aren't useful to the developers, the benefits they get
from them don't justify the time it takes to read them
2. They are time pressured
3. Your Gherkin isn't good enough, its probably far to long and full of
detail
4. Implementing your Gherkin is probably quite difficult
You say 'how do you make your developer stick to user stories during
development'
This suggests that
1. You believe your user story is something that you should stick to, i.e.
that you have learnt all there is to lean about the topic and that its just
the developers job to do what they are told.
If you want your developers to read your stories you should
1) Make them simple and useful.
2) Ensure they only talk about what needs to be done and why its
important. Give your developers more responsibility to determine HOW things
should be done
3) Allow you developers to challenge your stories
4) Realize much less is known about about that needs to be done when a
story is written than when a story is implemented, and treat the stories as
guidelines not instructions.
5) Give you developers more time (in particular allow them to start things
earlier)
Your presenting your developers with two artifacts, a picture and a story.
They are giving you clear feedback that the picture is useful and the story
isn't. You see that as a problem with your developers. Its much more likely
its a problem with your stories!
Most developers (in my experience) are time pressured to deliver alot of
functionality in a short period of time, and in particular to do what they
are told. BDD doesn't work for developers working under those conditions.
BDD is an agile process it only works of people realize that the process
is not about instruction but its about collaboration. Have 3 amigos get
together to produce instructions that the developers are then supposed to
deliver is not agile its waterfall and it really doesn't work. The amigos
should be working to produce guidance which is all about telling the
developers WHY something is important, and WHAT that something is, and then
getting them to start work on that before anyone has decided HOW things
should be done and before the UI has been designed. The whole point is to
get a minimal viable implementation early and then iterate having
stakeholders interacting and providing feedback so everyone communicates
and learns as the functionality is being developed.
Many many organizations think that having a scrum master and doing sprints
is Agile. Scrum can be agile but most of the time it isn't, its just mini
waterfall, or rushed waterfall or some other bastardization of waterfall. I
strongly suspect thats what is happening in your organization from what you
have written, and that is why your development process is not working as
well as you'd like.
Hope thats useful
All best
Andrew

Post by 80Vikram
Dear BDD warriors,
I am following BDD since last 2 years & in current project we follow
scrum/ agile with dedicated Agile Coach / Scrum master.
The process we follow is as below
*Before Sprint *
- PM writes acceptance criteria against multiple JIRA tickets relate to
a big feature
- As QA I write detailed user stories ( Gherkin Syntax ) as acceptance
criteria are quite abstract and lead to confusion, bugs
- I conduct "3 Amigos Session" with Dev ( Front End only ) & PM to
review, clarify and sign off user stories ( I do step 2 as my team thinks
writing stories together will waste their time, they are doing BDD first
time in their life )
- After "3 Amigos Session" both PM and Dev engineers appreciated and
liked detailed user stories in Given When Then format as it made things
pretty clear to them
*During Sprint*
- Daily standup to update to team how is work is getting progressed
*Post Sprint *
- Now the fun part starts, after sprint is over; I asked the same
developers again if they've referred to these user stories and answer was
BIG NO
- They have simply used design attached to ticket to write front end
code and told me that going through stories takes lot of their time
- One of the developer told me that he would have preferred if stories
are linked to design somehow ( we've design in invision app )
*My Queries to community ?*- During "3 Amigos Session" we had agreed
that developer will create sub-task based on user stories but they've
created based on design / screens
- How do you make your developer stick to user stories during development
or make them read it during development ?
- Or user stories are just for QA team in the end ( for doing manual
testing and writing automation with cucumber tool ) ?
- If you as well follow Agile / Scrum with BDD, please share your best
practices
Thanks in advance.
Regards,
Vikram
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org