Please enable JavaScript.

Coggle requires JavaScript to display documents.

Sprint Backlog - Coggle Diagram

- - - - Not legal without it
      - Unsafe without it
      - Cannot deliver a viable solution without it
    - - Should Have requirements are defined as:
      - Important but not vital
      - May be painful to leave out, but the solution is still viable
      - May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork etc. The workaround may be just a temporary one
      - One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected.
    - - Less impact if left out (compared with a Should Have)
      - These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best case scenario. When a problem occurs and the deadline is at risk, one or more of the Could haves provide the first choice of what is to be dropped from this timeframe.
      - Wanted or desirable but less important
    - - These are requirements which the project team has agreed will not be delivered (as part of this timeframe). They are recorded in the Prioritised Requirements List where they help clarify the scope of the project. This avoids them being informally reintroduced at a later date. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around. Won’t Haves can be very powerful in keeping the focus at this point in time on the more important Could Haves, Should Haves and particularly the Must Haves.