Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Features are generally linked to Epics and have a version assigned
  • A standard format for features is needed. Some features have a lot of details. However, the purpose and benefits of the feature can get lost in the long narrative. It could help to capture the essence of the feature (benefit hypothesis and success measure) in the description, then add a "note" section for more details. A good example of features that need better structured are IPHCD-2776, IPHCD-2776, IPHCD-2771
  • The statement of the Benefit Hypothesis can be improved. Instead of authoring the feature in the user story format, we recommend the following Benefit Hypothesis format: "We believe that by doing XXX action/activity/function, we will achieve YYY benefit". This helps to approach the feature as a hypothesis that can be TRUE or FALSE after implementation/experimentation (ex: IPHCD-2776, IPHCD-2776, IPHCD-2771)
  • Success measure instead of acceptance criteria: First the acceptance criteria is a To Do list or list of tasks instead of being binary criteria that can be validated (ex: IPHCD-2776, IPHCD-2776, IPHCD-2771)
  • The title of the feature is vague. It is should summarize the hypothesis that is put to test (ex: IPHCD-2776)

...