Toolkit
Impact Scan
Net Positive Sprint Kit - Part 7 of 9
Part 7 of 9 · Sprint Review
Use this tool
- At the end of a sprint, during the retrospective
- Before shipping a major release
- As part of a regular technical health review
You'll get
- A structured way to spot high-impact decisions or missed opportunities
- Quick wins to add into the next sprint
- A record of recurring issues to address over time
Setup
Guidance
Getting started
- Set aside 10-15 minutes in your retro or review session.
- Look at recently completed work.
- Ask the relevant prompts from the list below.
- Capture one or two improvements to bring into the next sprint.
Prompt list
| Area | Questions to ask |
|---|---|
| Experience design | Can the same outcome be achieved with fewer steps or interactions? Are we adding features users didn't ask for? |
| Interface and front-end | Are we loading assets or scripts before they are needed? Are we using heavy frameworks where lighter options would work? |
| Data and APIs | Are we making unnecessary or duplicate API calls? Could we cache results? |
| Libraries and packages | Are we carrying unused or bloated dependencies? Could a smaller library or built-in function do the same job? |
| Infrastructure | Are environments running when they are not needed? Could we scale down or switch off in low-usage periods? |
| Default behaviours | Do our defaults add unnecessary load (e.g. high-res images for all users)? Could we offer a low-impact default instead? |
| Real-world behaviours | Could this feature influence a positive action outside the product (e.g. reduced travel, shared resources, energy-saving habits)? |
Tips
- Avoid trying to fix everything at once - focus on one or two changes per sprint.
- Use Impact Tags to flag follow-up work if you can't act immediately.
- Share both the positives and the issues so the team can see the benefits of the changes.
- Check for trade-offs; consider any knock-on effects for accessibility, usability, or security.
Example
During an Impact Scan, a team found that a new dashboard was reloading data every 5 seconds. They switched to event-driven updates, significantly reducing API calls by replacing frequent polling with event-driven updates.
Output
A small set of actionable changes for the next sprint. Visibility of recurring patterns that may need bigger fixes.
Measurement & Validation
Count the number of impact improvements identified in a sprint. Optional: Compare proxy metrics (e.g. load time, page weight) for key user flows before and after changes.
Want help running a net positive sprint?
We facilitate net positive sprints for teams who want to embed sustainability into their digital delivery.