Events

The events required closely mimic what is found in generally-accepted Agile practice, with the exception of the suggestion of splitting Epic refinement into its own meeting. This is not completely necessary if you are continuing work with a known vendor team; the closer and more directly you can tie strategy to execution in your teams, the less noise will be introduced into the system.

---

Epic Backlog Refinement

• Frequency: occurs during the initial RFP process and/or at any point that a major change in strategy is identified by the customer.
• Duration: refinement events should be limited to 3 hours per day to limit target fixation and fatigue.
• Participants: may be done jointly with all potential vendors during the RFP process, or ad-hoc with a selected vendor.
• Outcomes:
  • An initial or superseding Schedule E, listing what large value items are being attempted for delivery.
  • An initial or superseding Schedule D with any new Definitions of Done that ALL value delivery must conform to.

---

Team Backlog Refinement

• Frequency: often held weekly until enough backlog has been broken down into smaller-than-Sprint-sized backlog items, to a point where a comfortable planning horizon for the Product Owner is established. Then refinement can be shorter and held mid-Sprint, to allow any new value from the PO to be refined by the team, for potential execution in the next Sprint.
• Duration: hold as many as needed to create the next Sprints’ worth of refined backlog, but no more than 3 hours in a single sitting to limit target fixation and mental fatigue.
• Participants: Vendor Dev Team, Vendor Scrum Master, Customer Scrum Master, Product Owner.
• Outcomes: enough refined backlog that the next Sprint (preferably several) will deliver value, with enough time for the Product Owner to react to their new understanding of the difficulty/uncertainty/complexity for the value, before Sprint Planning.
  • “Devs, do you understand what’s being asked of you?” – if not, the Product Owner elaborates, backlog item is clarified, potentially split.
  • “Devs, can you solve/deliver this inside a Sprint?” – if not, Devs and Product Owner negotiate a smaller problem to solve.
  • “How difficult/uncertain/complex is this to deliver inside a Sprint?” – Points are added to the product backlog item.

---

Sprint Planning

• Frequency: Beginning of each Sprint.
• Duration: no more than 8 hours for a 4-week Sprint, typically 1 hour for a software Dev team working 2-week Sprints.
• Participants: Vendor Dev Team, Vendor Scrum Master, Customer Scrum Master, Product Owner.
• Outcomes: a plan to deliver value that offsets the cost of the Sprint, captured on a signed Schedule C.

---

The Sprint

• Frequency: variable via Schedule A, but must be static for the duration of Schedule A. Meaning, it is strongly inadvisable to have one 2-week Sprint, then two 1-week Sprints, then one 4-week Sprint for an 8-week recurring cadence, as this makes basic budgeting exceptionally complicated, and incentivizes more traditional waterfall delivery every 8 weeks, instead of smaller deliveries (inspections) more frequently.
• Duration: less than 4 weeks, typically 1 or 2 weeks for modern software administration or development respectively.
• Participants: the Scrum Team (the Developers, Vendor Scrum Master, Customer Scrum Master, and Product Owner)
• Outcomes: a deployed solution, viable per the Definition of Done (the latest Schedule D), potentially releasable on the Product Owner’s authority to a customer, by the end of every Sprint.

---

Daily Scrum

• Frequency: Every day, at whatever time works for the developers. For global teams, there may need to be more than one Daily Scrum, to coordinate across geographies.
• Duration: no more than 15 minutes, this is not a status update meeting for the team or individuals, it is strictly coordination for the team for the day, and impediment escalation if needed. This meeting should not typically take more than 5 to 10 minutes, and must not be the only time or mechanism that the team members communicate with each other.
• Participants: All developers must attend. Neither the Vendor Scrum Master nor Customer Scrum Master are required, so long as impediments are brought to them respectively for removal.
• Outcomes: a coordinated plan, with accountability and commitment to deliver something of value for the day, with Developer impediments handed off to the Vendor Scrum Master or escalated to the Customer Scrum Master for removal.

---

Sprint Review/Demo

• Frequency: end of each Sprint.
• Duration: no more than 4 hours for a 4-week Sprint, typically 1 hour for a software development team working 2-week Sprints.
• Participants: the Scrum Team (Developers, both Scrum Masters, & the Product Owner), potentially customers, stakeholders, higher strategic leadership, etc.
• Outcomes: a demonstration of new solutions built by the team(s) this Sprint. This is not a review of software code, nor materials used, nor time spent; it is a review of tangible progress the team has made toward solving one or more problems, worth more than the cost of the Sprint, or taken as a strategic loss.

---

Retrospective

• Frequency: end of each Sprint.
• Duration: no more than 3 hours for a 4-week sprint, typically 1 hour for a software development team working 2-week Sprints.
• Participants: all developers, the Vendor Scrum Master, and the Customer Scrum Master, the Product Owner may or may not be invited (but will participate as a function of flow through the team, not as a strategic product guide), and stakeholders are specifically not invited, in order to create space where honest feedback will not result in excessive embarrassment.
• Outcomes: a deep inspection of the flow of work through the team may uncover opportunities for improvement, specifically the discovery of regular dependencies on other teams that could result in better partnership or refactoring of the team(s), and/or shifting learning/documentation/Definition of Done upstream.

---

A Note on Scaling Frameworks

Scaling these events for larger vendor teams is simple and dovetails directly into the industry-standard scaling frameworks, S@S/LeSS/SAFe or otherwise. Hold your scaled planning events (Refinements & Planning) sequentially with the highest-order strategy set first, highest to lowest. Hold your execution events (however you escalate impediments) with your individual teams working impediments, escalating issues they can’t resolve or haven’t resolved since the last Daily Scrum, lowest to highest.

Examples:

---

A Note on Blended Employee+Vendor Teams

It is common for new value/challenges to require a blend of existing customer (“FTE”) talent, augmented with vendor talent, in any ratio. It may look like 8 vendor Devs augmented by 1 FTE cloud solution architect with privileged access. It might be 6 FTE’s augmented by a single vendor data scientist for a few Sprints or even a few years. These are all normal modes, this should be expected. The only change that occurs is the accounting the Product Owner must do for the blended spend, ensuring the Sprint pays for itself across the sum of FTE/Vendor talent costs.

---