how_can_we_improve_collaboration_on_user_stories
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Last revisionBoth sides next revision | ||
how_can_we_improve_collaboration_on_user_stories [2020/06/10 12:50] – ↷ Page moved from blog:how_can_we_improve_collaboration_on_user_stories to how_can_we_improve_collaboration_on_user_stories hans | how_can_we_improve_collaboration_on_user_stories [2021/04/28 11:35] – Changed terminology to reflect more modern language hans | ||
---|---|---|---|
Line 5: | Line 5: | ||
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 " | 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 " | ||
- | 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, | + | One team I worked with recently ran an experiment using a slightly more formalized approach to capturing |
By way of background, when we tested during the first phase of the project, while we had good requirements, | By way of background, when we tested during the first phase of the project, while we had good 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 Satisfaction) which 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”, | + | 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”, |
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, | 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, |
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_can_we_improve_collaboration_on_user_stories.txt · Last modified: 2021/04/28 11:37 by hans