11 Scrum Steps to Get Twice the Work Done in Half the Time

Forget About Being an Expert. Become a Student of the Game.

There is a version of the Lean journey that most serious practitioners eventually encounter. The entry point was good. The early gains were real and visible. The workweek dropped, the project outcomes improved, the vocabulary changed, and the thinking changed. And then somewhere around year one or two, the improvement stopped. The plateau arrived. The tools were still in use, the principles were still being applied, and nothing was getting better. Something was missing.

This is the moment that separates practitioners who grow continuously from those who settle into a competent but static version of what they learned early. The response to a plateau is not to try harder with the same methods. It is to find the method that addresses the gap the current toolkit cannot close.

The Gap That Lean Alone Could Not Close

A chronic workaholic who began practicing Lean in 2009 got down to a consistent 55 to 60-hour workweek after the first year real progress, compared to what came before. But the improvement had stalled. The methods were being practiced. The principles were understood. And the output, the velocity, the capacity none of it was increasing anymore.

The solution arrived through an audiobook recommendation: SCRUM: The Art of Doing Twice the Work in Half the Time by Jeff and JJ Sutherland. The book explained why Scrum works. The 19-page Scrum Guide explained how to apply it. All that was needed was a wall, some sticky notes, and a marker.

The first application was not on a construction project. It was a single day at home with a three-year-old games, home chores, and genuine fun completed before dinner. That tiny test proved the principle Jeff Sutherland describes for getting started: just start. Start at home. Start at work. Start with one project or one major task. The Scrum framework scales in both directions.

Scrum Applied to Construction: The Change Order Sprint

The first construction application was a hard bid project with a backlog of change orders that had accumulated past the point where any normal project management rhythm could process them. The goal was to get them negotiated, accepted by the owner, and billable done, in the Scrum definition of done within a ten-day sprint.

The eleven major Scrum steps applied directly. The product was change orders done meaning negotiated, accepted, and billable. The team included the owner’s representative, multiple subcontractor project managers, trade managers, and a project accountant. The Scrum Master was the facilitator who owned the board and the process. The backlog was prioritized oldest and largest first, then newer and smaller and then adjusted daily based on feedback from the owner about which required additional stakeholder review.

Sprint planning took thirty minutes to organize and communicate what was planned. The initial goal was one change order per day, but the velocity increased quickly to two to three per day. The sprint board a whiteboard with sticky notes moving through To Do, Doing, and Done was visible to everyone in the office. The daily stand-up answered three questions: What did I do yesterday to advance the sprint? What will I do today? What is blocking me? The answer to the third question became the next task an impediment removed before anything else moved forward. At the end of the ten-day sprint: 20 negotiated change orders, all billable that same month, completed while maintaining all other daily project responsibilities. Two-week average velocity: ten change orders per week.

The Velocity Trajectory

The Scrum framework did not just complete a sprint. It broke through the improvement plateau that Lean alone had not been able to address. Starting with a velocity of less than ten points in the first sprint week where each sticky note task equaled one point the velocity grew consistently. By week six, the consistent average was above fifty points per week without any additional working hours. Scrum more than doubled the management capacity within the same time budget.

The improvement was visible enough that a promotion followed. Within two years, a Certified ScrumMaster designation was earned. Jeff Sutherland confirmed that this was the first certification from the construction industry not surprising, he noted, since Toyota itself was sending people for Scrum Master certification as part of one of its newest company initiatives. The alignment between Scrum and Lean is not incidental the Scrum Master role is largely modeled on Toyota’s chief engineer.

The Eleven Steps and What Each One Does

The complete Scrum framework consists of eleven steps that work together as a system not a menu from which selected parts are applied, but an integrated cycle that produces the velocity gains when practiced in full. Pick a product define what done looks like before beginning. Pick a team identify everyone whose participation is required for the product to get done. Pick a Scrum Master the person who owns the board, removes impediments, and protects the team’s sprint. Create and prioritize the backlog list everything that needs to be done and order it by what produces the most value first. Refine and estimate adjust priorities based on real-time feedback and estimate the effort of each backlog item.

Sprint planning a short session to communicate what will be accomplished in the next sprint and why. Make work visible the board, with its three columns of To Do, Doing, and Done, is the information radiator that makes the work and its status visible to everyone. Daily stand-up the three questions, walked through the board every day, fifteen minutes maximum. Sprint review a short meeting to evaluate what was accomplished and refine the remaining backlog. Sprint retrospective four questions that focus the team on learning: what went well, what can be better, what improvement can be made now, and what is the velocity? Repeat the cycle continues indefinitely.

Here are the signals that Scrum practice is building genuine velocity rather than just adding another process layer:

• The sprint goal is clear and specific enough that the team knows at the daily stand-up whether they are on track
• Impediments identified in the daily stand-up are resolved the same day before other work continues
• Velocity is tracked honestly across sprints and the trend is visible
• The sprint retrospective produces at least one specific improvement per cycle that is implemented in the next sprint
• The board is genuinely visible to everyone involved, not maintained privately by the Scrum Master

The Continuous Improvement Loop

What makes Scrum complementary to Lean rather than redundant with it is what it addresses. Lean focuses on the production system eliminating waste, creating flow, leveling work, and building the culture of continuous improvement. Scrum focuses on the knowledge work system organizing and prioritizing a backlog of complex, interdependent tasks, managing the work in short cycles with daily inspection, and building the team’s capacity to deliver more of the right work in less time.

A construction project manager practicing both operates at two levels simultaneously. The Lean production system governs how the field work flows the Takt plan, the Last Planner commitments, the daily huddle, the zone control walks. The Scrum framework governs how the management work flows the change orders, the submittals, the RFI responses, the coordination meetings, the procurement activities. The velocity of the management work determines how much support the production system receives. More management velocity means fewer blockers that reach the field, fewer delays in information, and faster response when problems surface.

Jeff Sutherland’s PDCA for knowledge work design, deliver, sustain has been in a continuous improvement loop from the moment the first sprint was completed. The velocity that started below ten points per sprint week grew above sixty. The workweek that started above sixty hours dropped and stayed manageable. The improvement that had plateaued restarted and sustained. If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your field teams stabilize, schedule, and flow. Just start. The velocity will follow.

On we go.

Frequently Asked Questions

What is the core purpose of Scrum in a construction management context?

To organize knowledge work submittals, RFIs, change orders, coordination activities, procurement into short, focused sprint cycles with clear goals, daily inspection, and continuous velocity measurement. It addresses the management work that supports the production system, complementing Lean’s focus on production flow.

What does velocity mean in Scrum and why is it the primary metric?

Velocity is the amount of work completed per sprint cycle, measured in points where each task is assigned a point value. It is the primary metric because it makes improvement visible and quantifiable a velocity that grows over successive sprints confirms that the team is getting better at delivering work, not just staying busy.

Why does the daily stand-up ask three specific questions?

What did I do yesterday to advance the sprint? What will I do today? What is blocking me? These three questions limit the stand-up to current sprint activity, surface impediments immediately, and ensure that every impediment becomes the next priority before other work continues. The structure prevents the stand-up from becoming a status report.

How does Scrum complement Lean construction rather than replace it?

Lean addresses the production system how field work flows through zones and trades. Scrum addresses the knowledge work system how management tasks flow through the project office. Both are necessary for a construction project to perform at its potential, and each becomes more effective when the other is functioning well.

Why is it important to start Scrum practice on small, low-stakes applications before using it on major project work?

Because the habits and disciplines that make Scrum effective daily stand-ups, board maintenance, sprint retrospectives, velocity tracking need to become natural before the stakes are high. Starting at home or with a single project task builds the muscle memory that makes the framework automatic when it is deployed on complex project work.