Default delivery process FAQ
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 default | Scrum | Kanban | Comment |
|---|---|---|---|
| Product Owner | Product Owner | N/A | Our 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 Lead | Scrum Master | N/A | We 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 member | Developer | Kanban system member | Other 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". |
| Iteration | Sprint | N/A | We 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 backlog | Product Backlog Items in the Product Backlog | Work items | Scrum 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 goal | Mandatory sprint goal and sprint backlog | N/A | The 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 & planning | Sprint planning | N/A | Instead 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-up | Daily Scrum | N/A | Scrum 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 Expectation | Burn down/up, cumulative flow | WIP, lead time, cycle time & Service Level Expectation | We 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. |
| Release | Increment | N/A | We 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 review | Sprint review | N/A | Our recommendation agrees well with the Scrum definition. |
| Retrospective | Sprint retrospective | N/A | Our recommendation agrees well with the Scrum definition, though we provide some more detailed guidance. |