We use cookies to improve your experience. By using our website, you consent to our Privacy Policy. I Accept
Menu

Delivery

Deliver products and features to maximise ROI. Create repeatable delivery mechanisms that allow incremental improvements and scalability

Section: Overview

Section

Sprint

Sprints are timeboxed delivery cycles where teams take on an agreed backlog of work. The team then progress each work item through the delivery pipeline to a point where is has been accepted by the Product Owner and can be deployed to live.

Whilst teams may have different variations on the stages that the work passes through within the Sprint, each stage must have a clear definition of done. The stages on the board below represent common themes within a Sprint SDLC.

Once a user story is ready to pick
Key Focus: Decomposition of Epics into smaller work items
Product Owner, Business Analyst & 3-Amigos

Sprint Planning / Sprint Backlog

  • Allows the team to come together to agree which User Stories will be addressed in the next sprint
  • Squad identifies expected capacity for sprint
  • Highest priority work items (that are ready) are sense checked by the team to fill the capacity
  • For each work item, the team ask themselves:
    • Do we understand what we’re trying to do?
    • Did the 3 Amigos get it (broadly) right?
    • Is there anything that means this couldn’t be done in the sprint?
  • Sprint Backlog is prioritisised by the PO and the team “works from the top” to ensure its lowest priority items that are at risk of not being delivered

Implementation (Build)

  • Aim is to implement the changes needed to deliver the functionality
  • Developers build against the pre-identified BDD Scenarios
  • BA support offered to identify any missing requirements and give guidance on ad-hoc queries
  • Example definition of done for the stage include:
    • Have we written our unit tests?
    • Are all the unit tests passing?
    • Does the code / changes deliver the requirements?
    • Has the code been peer reviewed?
    • Have Test & Dev liaised to make any necessary changes to the automated tests?
    • Have the testers verified that the acceptance criteria has been met?
    • Has the code been pushed to a test environment?
  • Sprint Backlog is prioritisised by the PO and the team “works from the top” to ensure its lowest priority items that are at risk of not being delivered

Test

  • Ensure that functionality works on a dedicated test environment
  • Tests focus on services to ensure the business logic works
  • May require ad hoc analysis from the BA (“Should the system…”)
  • Also includes Exploratory Testing and Performance Testing (if necessary)

UAT (Product Sign Off)

  • Final story level demo / exploratory test with Product Owner
  • Acceptance Criteria used as definition of done
  • Tests used as proof of functionality
  • May increase backlog as it generates conversations around additional scope
  • Should be a continuation of conversations between the PO and other team members at other stages of the Sprint
  • Can be done during the sprint demo, although this doesn’t leave time for the team to re-work any issues within the sprint

Ready for Release

  • Stockpile of “dev done” items that can be progressed outside of the sprint.
  • In reality this could mean ‘ready for sprint demo’ or even ‘awaiting release approval’ for teams who are not operating in a continual integration pipeline
  • Aim for work items in the column to move to next stage as soon as possible as the is the last stage of inventory before value is realised so shows the mostly costly area waste within the process

Live

  • Change is live, toggled on and with the end user