As a supplement to Scrum Exoskeleton from scrum.org,
I use the illustration below to map the journey of a requirement from their sources to their deployed form. My teams use this to describe the flow of value and to easily determine what activities they should perform to complete a requirement.
The flow of requirement to a working product passes through filters,
Filter 1: The Product Vision Test
Requirements should pass the Product Vision test before it is considered to be included in the Product Backlog
- Are the WHYs and the WHATs of the requirement clear?
- Does the requirement contribute to the product vision?
- Does it add value (benefit, risk reduction or opportunity enhancers)?
When all the answers are YES, the Product Owner will write the related Epic/ Themes to the Product backlog. Else, the requirement should be removed.
Filter 2: Definition of Ready
Before a requirement is considered for implementation, it should pass the Definition of Ready. This will vary from team to team. At the minimum it should be:
- CLEAR: everyone understands the WHAT and the WHY of the Product Backlog item
- SMALL: the product backlog item can be implemented in 1 sprint that complies with the definition of Done
- TESTABLE: acceptance criteria can be defined
The themes or epics from Filter 1 should be broken down, decomposed, and refined. I prefer user journey mapping technique to identify user stories of a given requirement. The output of this filter are READY user stories.
For more information about Product Backlog Refinement, please refer to my previous article, Everything about Product Backlog Refinement.
Filter 3: Sprint Planning
READY Product backlog items are selected for implementation during Sprint Planning. The selection will depend on its prioritization (as influenced by the Product Roadmap) and its relevance to the current sprint goal.
The User Stories are decomposed further into tasks and as a whole monitored in the Sprint Backlog.
To assert the acceptance criteria, I prefer that User Story acceptance tests are written and executed in a BDD (Behavior-Driven Development) environment. Unit testing are performed through TDD (Test-Driven Development) and executed daily through a Continuous Integration Environment.
Filter 4: Acceptance Criteria and Definition of Done
A User Story is considered to be DONE when it passes its acceptance criteria and its Definition of Done. The Development Team should not wait for the Sprint Review to validate the DONENESS of User Stories. They should ask the P.O. or her representative to confirm User Story completeness.
For more information about Definition of Done, please refer to my previous article, Everything about Definition of Done.
Filter 5: Sprint Review
During the Sprint Review, the Product Owner, from the inputs of the stakeholders decide whether the completed story should be included in the Increment or placed back to the product backlog for further enhancement.
Filter 6: Release Decision
Not all increments are immediately released for deployment. It is a business decision decided by the Product Owner.
When the Product Owner decides to release the increment (cumulative done stories including those stories not previously released), DevOps/Continuous Delivery release cycle is executed to deploy the release into production.
When the product is deployed, new requirements and defects are discovered. These requirements go through the same Journey (Funnels) .
– Agile Pinoy