- What Scrum means for manufacturing improvement
- Visual map of Scrum applied to improvements
- Roles, events and artifacts
- How to build the improvement backlog
- Example: a 48-point backlog and team velocity
- One sprint cycle in practice
- When to use Scrum and when to pick something else
- Common mistakes
- Frequently asked questions
What Scrum means for manufacturing improvement
Scrum is an agile framework that organizes work into short cycles of 1 to 4 weeks called sprints, with a prioritized backlog, a small team and a review at the end of each cycle. In a plant it suits improvement projects with many ideas and little available time: the team delivers one concrete improvement per sprint instead of waiting for a long project to close.
Scrum does not replace the shop floor or Lean. It organizes the management of the improvement work, while daily production keeps following the plan and Lean daily management.
Visual map of Scrum applied to improvements
The map shows the roles, the sprint cycle and the 48-point backlog example.
Roles, events and artifacts
The Scrum Guide (Schwaber and Sutherland) defines three accountabilities, five events and three artifacts. Translated to a plant improvement effort:
| Element | In Scrum | In manufacturing improvement |
|---|---|---|
| Product Owner | Owns the backlog | Manager or engineer who prioritizes by impact on cost, quality or safety |
| Scrum Master | Facilitates the method | Lean coach or improvement lead who removes blockers |
| Team | Delivers the increment | 3 to 7 people: operator, maintenance, quality, engineering |
| Backlog | Prioritized list | Improvement ideas estimated in points |
| Sprint | 1 to 4 week cycle | Improvement cycle with a clear goal |
| Daily | 15-minute sync | Stand-up at the station or the board |
| Review and retrospective | Inspect and adapt | Show the result at the gemba and adjust the method |
The logic is PDCA at a fixed rhythm: plan at sprint planning, do during the sprint, check at the review and act at the retrospective.
How to build the improvement backlog
The backlog holds everything you want to improve, in priority order. Good sources are operator ideas, audit findings, the value stream map and the 7 wastes. Each item needs three things: a clear description, a definition of done and an estimate.
Estimating in points is relative: it measures effort and uncertainty, not hours. Relabeling tools is a 3, an error-proofing fixture is an 8. The team compares items with each other, often using 1, 2, 3, 5, 8, 13. Anything above 8 should be split.
Example: a 48-point backlog and team velocity
Fictional example: a team of 5 people, 2-week sprints (10 working days) and the backlog below, already in priority order.
| Rank | Item | Points |
|---|---|---|
| 1 | Poka-yoke on the torque sensor | 8 |
| 2 | Start-of-shift checklist | 4 |
| 3 | Visual management in the cell | 3 |
| 4 | Tool labeling | 3 |
| 5 | 5S kit for the assembly station | 5 |
| 6 | Work instruction for station 4 | 5 |
| 7 | Quick changeover (SMED) on press P2 | 8 |
| 8 | Supermarket replenishment | 8 |
| 9 | Rework in the paint area | 4 |
| Total | 48 |
Velocity is the average of points completed in earlier sprints. In the last three the team closed 11, 14 and 12: (11 + 14 + 12) ÷ 3 = 12.3, rounded to 12 points per sprint.
Sprints needed = backlog points ÷ velocity = 48 ÷ 12 = 4 sprints (8 weeks)
In sprint 1 the team commits to items 1 and 2: 8 + 4 = 12 points, with the goal "stop out-of-spec torque and standardize the start of shift". The ideal burndown falls 1.2 points per working day: 12 left on day 0, 6 on day 5 and 0 on day 10. If the real line sits above the ideal one mid-sprint, the team cuts scope, never quality.
| End of sprint | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Points left in backlog | 36 | 24 | 12 | 0 |
One sprint cycle in practice
- Planning (2 h): the team pulls items up to its velocity and sets the sprint goal.
- Daily (15 min): standing at the board: what I finished, what I will do, what blocks me.
- Execution: improvements happen at the station with quick trials; the board follows the kanban board logic (to do, doing, done).
- Review (1 h): the team shows what changed on site, with before and after data.
- Retrospective (1 h): the team decides what to keep and what to change in its own method.
When to use Scrum and when to pick something else
- Use it when there are many small improvements, uncertain scope and a need for visible results within weeks, as in these kaizen examples.
- Prefer a schedule when the sequence is rigid and known, such as installing a line: use the Gantt chart and the WBS.
- Prefer the 5-day event for a single, bounded problem: see the kaizen event.
- Combine both in large programs: Gantt for milestones, sprints for detailed execution.
Common mistakes
- Adopting the vocabulary without the method: meetings with new names but no prioritized backlog.
- Staffing the team with people who give it 10% of their time; velocity never stabilizes.
- Using velocity to compare teams or chase productivity; it exists only for planning.
- Changing scope mid-sprint without renegotiating the goal.
- Skipping the retrospective: without it the method does not improve.
- Delivering "almost done": an item not tested at the station earns no points.
Frequently asked questions
Does Scrum work in manufacturing?
It works for improvement work, product development and planned maintenance. It is not meant to control production flow itself; kanban and production scheduling do that.
What is the ideal sprint length?
For plant improvements, 2 weeks is usually the balance: short enough to correct course, long enough to test at the station.
What are story points?
A relative measure of effort and uncertainty. They compare items with each other and do not measure hours.
How do I calculate how many sprints a project needs?
Divide the backlog points by the average velocity. In the example, 48 ÷ 12 = 4 sprints.
What is the difference between Scrum and kanban?
Scrum works in fixed cycles with a goal commitment; kanban works as continuous flow with a limit on work in progress.
Does Scrum replace PDCA?
No. It gives PDCA a rhythm and roles; PDCA remains the logic of learning and standardizing.
Sources
- SCHWABER, K.; SUTHERLAND, J. The Scrum Guide. Scrum.org, 2020.
- SUTHERLAND, J. Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business, 2014.
- TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, 1986.
- ANDERSON, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
Keep studying: trusted sources and links
- PMI: Standards and publications (PMBOK Guide)
- ABEPRO: Associação Brasileira de Engenharia de Produção (in Portuguese)
- Wikipedia: Project management
- Wikipedia: Kaizen
Save this address: Manufatura Enxuta is your school for lean manufacturing. Come back whenever you need to study, with a complete article, a visual map and trusted sources. Follow one of the learning paths or check the A–Z glossary.
Want to lead change with a method?
Download the free e-book Lean for Leaders and see how to sustain lean culture day to day.
Download the e-book
About the author
Lean Manufacturing & Behavioral Management Specialist
Over 20 years in the automotive and metalworking industries (GM and Dana), Lean Manufacturing practitioner since 2006. SENAI instructor and mentor in Brazil’s Brasil Mais Produtivo program, delivering consulting, training and audits for 50+ companies, combining quality, productivity and people development.
