A sprint is a bounded chunk of work in an agile development process. Teams organize its work as tickets in a backlog, clarify how tasks will be performed, and review completion with a checklist. Sprint work is iterative: findings can send tasks into later sprints or require earlier work to be redone. section 1.4 section 4.3.1
A machine-learning delivery project uses sprints to reduce uncertainty in stages:
- Sprint 0 prepares the team: secure access and permissions, agree working practices, verify infrastructure and data, assess risks, and confirm feasibility and estimates. section 4.0 section 4.1
- Sprint 1 opens the data using the new infrastructure, establishes versioning and pipelines, and begins data tests that make delivery more robust. section 5.0
- End-of-sprint checklists verify completion and documentation, creating an evidence trail that supports communication, maintenance, and production governance. section 1.4 section 4.8
Sprint 0 as a delivery buffer
Before the team begins expensive project execution, it uses sprint 0 to request accounts, resolve access problems, align with the customer’s infrastructure, investigate data resources, and agree communication, documentation, privacy, security, and ethics plans. section 4.0 section 4.1
| Task # |
Item |
| Setup 1 |
Create, communicate, and finalize the team design and resourcing. |
| Setup 2 |
Agree on and share a way of working: ▪ Project heartbeat (the day-to-day way the project will run) ▪ Work standards and best practices Agree on a common set of tools. Create, agree on, and share the communication plan. Create and share the documentation plan. |
| Setup 3 |
Build and share the infrastructure plan. |
| Setup 4 |
Undertake a pre-project data investigation. |
| Setup 5 |
Review project CSR and ethics. Build and share the privacy, security, and data-handling plans. |
| Setup 6 |
Build and share the project roadmap. |
Browse the sprint 0 backlog to inspect the concrete setup tickets for team design, working agreements, infrastructure, data investigation, governance, and the roadmap. section 4.1
| Item |
Notes and examples |
| Description of data |
Does an adequate life history for the data resources exist? This is a discursive description of what the data is (domain, source systems, scale, timeframe, etc.). Does the overview seem consistent and sufficient? Has the data description been validated with any data experiments or with any other method? |
| List of supplied data tables and other data sources |
Name of the table and a description of contents (e.g., customer master, customer type hierarchy). Name and description of other data sources (e.g., sensor, aggregated sensor platform) and connectivity details. |
| Limitations or problems |
Description of known problems with the data. Document any unexplained or unclear steps in the data’s origin. |
| Business uses |
Outline of known business uses of this data to date (how the customer currently uses it). |
| Documentation plan |
Ensure that a date for delivery is defined for all mandated documentation and that it is feasible for these documents to be created and delivered on time. Ensure that resources are allocated for the delivery of the documents. |
| Project roadmap |
Provide a high-level breakdown of how the ultimate outcome of the project is to be achieved. |
| Communication plan |
Ensure that adequate touchpoints with the project’s stakeholders (internal and external) are established. |
| Infrastructure plan |
Resourcing and time are in place to deliver the required working environment and development infrastructure. |
| Team design |
Delivery resources are identified and available for the project to be successfully executed within budget. |
| Project heartbeat |
List planned meetings across the project duration, the purpose of each meeting (sprint-planning, retrospective); include the daily stand-up schedule and attendance list. |
Browse the sprint 0 checklist to review completion evidence for data descriptions, sources, limitations, and business uses. section 4.8
