Page History

...

• 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 of features that need better structured is are 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 implementation/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 instead of being 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
  • Value statements missing juxtapose internal and external users and value statement
  • Acceptance criteria are broad and not binary
  • Story titles are vague at times. This could be due to:
    • The LACE not knowing your work well
    • The scope of the stories is too large