Story Development

The fourth of nine (9) Version Control topics describes the development lifecycle of a Story or Bug.  It provides technical detail behind the Implementation Task 4 - Story Build.  It covers Story States "Ready" through "Done".

Story Build (Development)

For each Story selected & added to the Sprint Backlog during the Sprint Planning Event:

On This Page
    Add a header to begin generating the table of contents
    Story Development

    Story Build Board

    States from 'To Do' to 'Functional Review'

    * In the steps below, substitute 'Bug' for 'Story' if dealing with a defect.  Ensure the proper Branch Type is assoctiated with each.

    1. When work begins the Solution Analyst (i.e., Developer):
      a) Creates a Story Branch from the parent Build Branch; and
      b) Progresses the Story from “Ready” to ‘In Progress’ on the Story Build Board.
    2. Changes are made on the Story Branch using developer’s Local Machine. Per this bullet’s number, this will be referred to throughout this explanation as “Dev Step 2”.
    3. On a periodic basis - at least daily, but more frequently if needed - Developer will:
      a) Merge their Story Branch to the Work Branch.
    4. Developers build & deploy the updated Work Branch to DEV1 as needed.  Developers should execute any Unit Tests  expected of the changes using the DEV1 environment rather than their Local Machine.
    5. Test Analyst now executes Functional Tests on the Story’s available functionality in DEV1.
    6. If Test Analyst (or anyone) finds errors with the Story, or if more development is needed to complete the Story:
      a) Developer returns to Dev Step 2 above and continues building.
    7. Repeat the above steps until Story development is complete and Functional Tests well underway, then
      a) Developer progresses the Story from ‘In Progress’ to ‘Technical Review’ on the Story Build Board.
    8. The Tech Lead will review the changes made. If this Technical Review fails:
      a) Tech Lead will regress the Story state back to ‘In Progress’ on the Story Build Board; and
      b) Developer will return to Dev Step 2 above.
    9. Repeat the above steps until Technical Review passes + all Functional Tests pass, then:
      a) Tech Lead progress the Story from ‘Technical Review’ to ‘Functional Review’ on the Story Build Board.
    10. Solution Owner (and SMEs) conduct a Functional Review. If it fails (or any additional changes are sought):
      a) SO will regress the Story back to ‘In Progress’ on the Story Build Board; and
      b) Developer will return to Dev Step 2 above; or
      c) Scrum Master, when appropriate, will regress* the Story to an earlier state and remove it from the Sprint.

    11.Repeat the above steps until Functional Review passes.

    States from 'Functional Review' through "Done"

    1. As each Story passes Functional Review:
      a) SO progresses the Story from ‘Functional Review’ to ‘Ready for Testing’ on the Story Build Board;
      b) Developer submits a Pull Request for the Story to merge from the Story Branch to the Build Branch; and
      c) Tech Lead approves outstanding Pull Requests for Stories in ‘Ready for Testing’ state.
    2. The Developer then:
      a) Merges approved Story objects from the Story Branch to its parent Build Branch. 
    3. DevSevOps (or Automated):
      a) Deploys the updated Build Branch to TST1; and
      b) Progresses Story from ‘Ready for Testing’ to ‘In Testing’ on the Storay Build Board.
    4. Test Analyst, or other Team member, executes Integration Tests in TST1, testing as much as possible.
      Do not stop at the 1st error found; find as many as possible.
    5. If errors are found:
      a) Test Analyst regresses the Story to ‘In Progress’ on the Story Build Board; and
      b) Developer returns to Dev Step 2 (see column to the left).
    6. Repeat the above steps until all Integration Tests pass, then:
      a) Test Analyst progresses Story from ‘In Testing’ to ‘Ready for Sign-Off’ on the Story Build Board; and
      b) Tester compiles Functional & Integration test results to support pending Story demo.
    7. Team demos each Feature as it evolves in TST1, showing progress toward completion, highlighting new Story (or Stories) from the current Sprint.
    8. Based on the Demo results, if the Solution Owner (SO) either:‘Accepts’ the changes “as is”,
      a) Scrum Master progresses the Story from ‘Ready for Sign-Off’ to “Done”; and
      b) the Story Branch ends.

      ‘Rejects’ the changes and time remains in the Sprint to correct:
      b) Scrum Master regresses the Story to ‘In Progress’; and
      c) Developer returns to Dev Step 2;

      ‘Rejects’ the chanages and not enough time remains in the Sprint to correct:
      d) Scrum Master regresses Story to “Ready” (or earlier state if appropriate) and removes it from Sprint.

    Scroll to Top