Product backlog
All features, functions and ideas for the product are logged in the backlog. Stakeholders continue to add to the backlog throughout the life of the product as new requirements and challenges come to light. Each item in the backlog is expressed as a simple statement and is categorised by themes or epics.
Each item in the backlog is prioritised based on ‘business value’. Items with the highest business value are turned into ‘stories’ in preparation for the next stage. The backlog is re-prioritised on a regular basis to reflect changes in the business environment.

Prioritised stories are assessed by the team and ‘pointed’ to provide a relative size that allows the product owner to evaluate the ‘cost’ of each story’s business value and how it fits with the team’s capacity.

Using its experience, the team calculates its capacity for the next sprint. Each prioritised and groomed story is broken down into tasks and estimated, until the team determines the sprint capacity has been consumed.

Development is prioritised based on business value and risk. Each story is developed to completion before new stories are started. Collaboration is facilitated through daily scrums, opening and closing conversations, peer reviews and daily in-flight testing.

Test scripting and execution follows the development prioritisation and is undertaken in parallel to the development. As each task is completed it is subjected to some form of daily testing – automated unit, peer review, in-flight, scripted, automated, performance. ‘Test early’ is the mantra that drives this process.

At the end of the sprint the team reviews the fully completed stories with the product owners and other stakeholders to determine if each story will deliver the expected business value.

The team review their performance in the sprint with three questions. What should we keep doing? What should we stop doing? What should we start doing? The outcomes are discussed and actions prioritised for the next sprint to ensure continual improvement.
Sprint deliverable
At the conclusion of each successful sprint there is a fully working and tested deliverable ready for review, feedback and potentially deployment and use by the customer. This approach of small and frequent deliveries allows the product owner and the customer stakeholders to fine tune the direction of the development as it progresses.
At regular points in the project, a formal release is made incorporating the output of multiple sprint cycles. These releases will typically include additional ‘formalised’ content that typify enterprise product deliverables, over and above the sprint deliverables.