User Tools

Site Tools


how_can_we_improve_collaboration_on_user_stories

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
blog:how_can_we_improve_collaboration_on_user_stories [2016/10/12 13:01] – ↷ Links adapted because of a move operation hpsamioshow_can_we_improve_collaboration_on_user_stories [2021/04/28 11:37] (current) – Reflect modern usage hans
Line 3: Line 3:
 > "Everything is vague to a degree you do not realise till you have tried to make it precise" -- Bertrand Russell > "Everything is vague to a degree you do not realise till you have tried to make it precise" -- Bertrand Russell
  
-When it comes to understanding and documenting requirements there always seems to be a discussion and room for improvement. In general we capture a user story in an automated tool with a summary / title and a description that has both the user story (“as a”, “I want”, “so that”) and a section describing the "Conditions of Satisfaction" (aka "Acceptance Criteria"). People wonder “how much is too much detail?” Others wonder whether they really understand the requirement in enough detail to do something useful. Still others think that we should write a complete specification.+When it comes to understanding and documenting requirements there always seems to be a discussion and room for improvement. In general we capture a user story in an automated tool with a summary / title and a description that has both the user story (“as a”, “I want”, “so that”) and a section describing the "Acceptance Criteria" (aka "Conditions of Satisfaction"). People wonder “how much is too much detail?” Others wonder whether they really understand the requirement in enough detail to do something useful. Still others think that we should write a complete specification.
  
-One team I worked with recently ran an experiment using a slightly more formalized approach to capturing Conditions of Satisfaction which helped us understand the requirement, but also did not specify how solution was to be derived. At the time we were trying to solve a problem with the (acceptance) testing of the workflows but found that the solution we worked also helped us improve the discussion and collaboration around the requirements.+One team I worked with recently ran an experiment using a slightly more formalized approach to capturing Acceptance Criteria (or Conditions of Satisfactionwhich helped us understand the requirement, but also did not specify how solution was to be derived. At the time we were trying to solve a problem with the (acceptance) testing of the workflows but found that the solution we worked also helped us improve the discussion and collaboration around the requirements.
  
 By way of background, when we tested during the first phase of the project, while we had good requirements, we really had not taken the time to develop a good test plan, relying instead on an ad-hoc approach. The result was that we did not feel we had covered all the basics. We felt that we had duplicated efforts in some areas. To improve we decided to capture the acceptance tests during the development of the requirements. By way of background, when we tested during the first phase of the project, while we had good requirements, we really had not taken the time to develop a good test plan, relying instead on an ad-hoc approach. The result was that we did not feel we had covered all the basics. We felt that we had duplicated efforts in some areas. To improve we decided to capture the acceptance tests during the development of the requirements.
  
-For the second phase of the project we used a format for the Conditions of Satisfaction which is related to acceptance test or behavior driven development. The basic format of the acceptance criteria is described as:+For the second phase of the project we used a format for the Acceptance Criteria (or Conditions of Satisfactionwhich is related to acceptance test or behavior driven development. The basic format of the acceptance criteria is described as:
  
 > Given <some initial context> > Given <some initial context>
Line 15: Line 15:
 > Then <ensure some outcomes> > Then <ensure some outcomes>
  
-The work we were doing involved the flow of data between Siebel and JIRA. Let’s say we have a user story “As a support engineer I would like see what is happening as people discuss and work a Siebel issue so I can ensure that it’s heading in the right direction”, we would then write the Conditions of Satisfaction as “Given a person is in working in JIRA Agile, when the person adds a comment to the JIRA issue that is linked to a Siebel CR then the related Siebel record notes will by updated with the comment”.+The work we were doing involved the flow of data between Siebel and JIRA. Let’s say we have a user story “As a support engineer I would like see what is happening as people discuss and work a Siebel issue so I can ensure that it’s heading in the right direction”, we would then write the Acceptance Criteria (or Conditions of Satisfactionas “Given a person is in working in JIRA Agile, when the person adds a comment to the JIRA issue that is linked to a Siebel CR then the related Siebel record notes will by updated with the comment”.
  
 Just like the user story format helps us capture and understand not only the feature but who needs it and why this format for the acceptance test helped us capture and understand the acceptance criteria from an end user’s perspective. It also helped us understand what it meant to test the capability when that time came around, forming the basis of our test plan. It really increased the amount of discussion we had about the requirements, and made things clearer for everyone. Just like the user story format helps us capture and understand not only the feature but who needs it and why this format for the acceptance test helped us capture and understand the acceptance criteria from an end user’s perspective. It also helped us understand what it meant to test the capability when that time came around, forming the basis of our test plan. It really increased the amount of discussion we had about the requirements, and made things clearer for everyone.
Line 24: Line 24:
  
 Note: Good starting book to read if you want to learn more is [[:bridging_the_communication_gap_-_specification_by_example_and_agile_acceptance_testing_-_gojko_adzic|"Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing" - Gojko Adzic.]] Note: Good starting book to read if you want to learn more is [[:bridging_the_communication_gap_-_specification_by_example_and_agile_acceptance_testing_-_gojko_adzic|"Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing" - Gojko Adzic.]]
- 
-Note: this posting was originally published [[http://www.hanssamios.com/wordpress/2015/08/27/improving-stories-with-given-when-then-format-for-conditions-of-satisfaction/|in August 2015 on a Wordpress Blog]] 
  
 {{tag>UserStory BlogEntry FAQ AcceptanceCriteria ConditionsOfSatisfaction}} {{tag>UserStory BlogEntry FAQ AcceptanceCriteria ConditionsOfSatisfaction}}
  
-~~LINKBACK~~ 
-~~DISCUSSION~~ 
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_can_we_improve_collaboration_on_user_stories.1476302481.txt.gz · Last modified: 2020/06/02 14:32 (external edit)