4.5 Requirements management

Figure 4.5: Requirements in Agile

  • Stories – statement of requirement, defining a stand-alone portion of functionality in the everyday or business language. Fine granular. May also be written to developers for non-functional requirements (performance, security, etc.)
    • Have a format:
      • Title:
        • As a [ROLE] I would/should/must [DO SG] to be able to [ACHIEVE SG]
      • Acceptance criteria detailed
      • Linked to an Epic, can have labels, Planned release version labels and a Fix version
      • E.g.:
        • As an end-user I must be able to add search criteria on the UI to make me able to find services on-line with the on-line Yellow pages software.
          • Acceptance criteria:
            • On the UI there must be two fields:
              • Search by name: text field of a max. of 30 characters
              • Search by phone number: text field, validating that only [0-9] numerical entry is provided
              • Only one field is to be filled; if one has even only 1 character of entry, other field will get disabled and turned into grey on the push of a key
            • Below the fields, there is a search button: on click, search is started (functionality detailed in related user story, ID: Phonebook-2)
              • On click validation of 30 char limit and numerical entry is provided; if validation fails, pop-up is shown (functionality detailed in related user story, ID: Phonebook-3)
            • EPIC link of the Story: “Phonebook-Search”
  • Tasks – small pieces of work required to complete a story; including low level technical details needed for engineers
  • Epics group user stories defining the same functionality. Block of requirements.
    • E.g. Search & view results of phonebook
  • Product backlog
    • A prioritized list of user stories, representing Stakeholders' needs and requests
      • The higher the priority is, the higher the likelihood is to add the item to the next Sprint's Backlog (which is a distinct list of items committed for the upcoming Sprint)
    • Requests range from functional to non-functional requirements, technical infrastructure requests, support and maintenance tasks.
    • What is not in the backlog, should not be taken care of
    • PO is responsible to maintain the backlog
    • Backlog items have estimates
  • Sprint Backlog
    • List of items committed to be done for the actual Sprint