Skip to main content

Default delivery process FAQ

Last updated: 2022-05-23

How does the default delivery process relate to Scrum and Kanban?

The defaults have a lot of overlap with both Scrum and Kanban and draws from both of these frameworks.

Recommended defaultScrumKanbanComment
Product OwnerProduct OwnerN/AOur usage agrees well with the Scrum definition of Product Owner. However, we recognise that the ideal of having one fully empowered and accountable Product Owner may not be easily achieved in all engagements.
Delivery LeadScrum MasterN/AWe do not have a role of Scrum Master at Infinity Works but we do have Delivery Leads, which is the closest equivalent. See comparison of delivery lead and scrum master.
Team memberDeveloperKanban system memberOther than the Product Owner, Scrum calls all team members "Developers", including roles such as BA's, visual designers, and testers. Kanban uses a framework-specific term. We avoid these arguably confusing usages and settle for the straightforward "team member".
IterationSprintN/AWe use the term iteration for a regular delivery cycle which includes planning, a retrospective and a review. We recommend a two week duration in comparison to Scrum's "one month or less". However, we recommend Kanban-style continuous flow.
Epics in the epic roadmap and backlog items in the backlogProduct Backlog Items in the Product BacklogWork itemsScrum and Kanban are deliberately nonspecific about the items being worked on. But we provide more guidance and make specific distinction between high-level epics and lower-level backlog items which are of the right level of detail for implementation. These are ordered in an epic roadmap and backlog respectively. Scrum uses the generic term Product Backlog Item to represent items of all sizes and the Product Backlog is the single list of all these variously-sized items. Kanban does not make mention of a backlog and deals only with the flow of Work Items once in progress.
Optional iteration goalMandatory sprint goal and sprint backlogN/AThe sprint goal is a central feature of Scrum and the sprint backlog is the set of backlog items which will deliver the goal. The goal is immutable once chosen for a sprint, and the sprint backlog is modified as needed to ensure the goal is delivered. If the goal cannot be delivered, the sprint can be "cancelled" and a new sprint started with a different goal, thus breaking the usual regular sprint cadence. Instead of this, the recommendation is for continuous flow where work on individual backlog items and epics may span (hopefully no more than two) iterations. So stating the iteration goal is less relevant, since the context is well provided by the epic roadmap, and the "sprint backlog" is not a relevant concept.
Regular refinement & planningSprint planningN/AInstead of the once per sprint/iteration planning session advocated by Scrum, we recommend two distinct activities: (a) frequent (default twice weekly) refinement of epics and backlog items to prepare them to be taken into implementation, and (b) slightly less frequent (default every 2 weeks) planning sessions to update the epic roadmap. This allows the team to be more responsive to changing circumstances compared to the more rigid sprint cycle of Scrum.
Daily stand-upDaily ScrumN/AScrum says this is a "15-minute event". The recommendation is the same in spirit but doesn't state a specific duration. We do make specific recommendations on the format which Scrum does not provide guidance on.
WIP, lead time, cycle time & Service Level ExpectationBurn down/up, cumulative flowWIP, lead time, cycle time & Service Level ExpectationWe recommend Kanban-style continuous flow, and so adopt the Kanban indicators of healthy delivery. Continuous flow allows the team to be more responsive to changing circumstances compared to the more rigid sprint cycle of Scrum.
ReleaseIncrementN/AWe use terminology which is in common usage but the meaning agrees with Scrum's definition. The release of software is not tied to the delivery cycle and can happen at any time, subject to successful validation.
Iteration reviewSprint reviewN/AOur recommendation agrees well with the Scrum definition.
RetrospectiveSprint retrospectiveN/AOur recommendation agrees well with the Scrum definition, though we provide some more detailed guidance.