Page History

...

The HCD backlog is composed of 2 main types of requirements: Features and User stories. The Features are larger requirements and can be decomposed into smaller requirements called user stories. This section aims to analyze the features and stories.

• Feature:
  • 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 is a feature that may be better structured is IPHCD-2776, IPHCD-2776
  • 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 experimentation (ex: IPHCD-2776, IPHCD-2776)
  • Success measure instead of acceptance criteria: First the acceptance criteria is a To Do list or list of tasks and not binary criteria that can be validated (ex: IPHCD-2776, IPHCD-2776)
  • The title of the feature is vague. It is should summarize the hypothesis that is put to test (ex: IPHCD-2776)
• User Story:
  • The active sprint shows that each user story is linked to a feature and most of them are assigned to a version.
  • Each story is also assigned to a team member and is estimated in story point. There are stories with the size "0". It would be important to understand why or the rationale behind it.
  • Acceptance criteria read as tasks and include inter-team collaboration
  • Notes and tasks are referenced that are not included as a user story
  • Not all stories have value statementsValue statements missing or mixture
  • Acceptance criteria are broad and not binary