When to Use Scrum?

When to Use Scrum for software projects?

By Kevin Thompson, Ph.D.

Scrum is a lightweight agile process framework used primarily for managing software development.

Scrum is:

• • Lightweight because it has few prescribed elements
    • • Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)

     

    • • Three meetings: Sprint Planning, Daily Scrum, Retrospective

     

    • • Three artifacts: Product Backlog, Sprint Backlog, Burndown chart

     

     

 

• • Agile because it maximizes responsiveness to changing customer needs

 

• • A process framework because it is not a process, but a collection of practices and concepts around which a process can be built

 

Scrum is often contrasted with the so-called “Waterfall” approach, which emphasizes up-front planning and scheduling of activities, followed by execution. Both approaches require careful planning, followed by execution and tracking, but the details of how these steps are accomplished are different.

 

Scrum

Scrum processes are cyclical, repeating every few weeks. Product Owners provide requirements, in the form of Stories (short narrative descriptions). The Team of developers and QA engineers implements the Stories in a Sprint of 2—4 weeks in length. During the Sprint, Team members work with Product Owners to refine and clarify requirements, to ensure proper implementation. Final requirements are defined by test cases created by QA engineers, and are used to validate each story to confirm that it is complete.

Stories are implemented in rank order, one at a time, to ensure that highest-priority requirements are implemented first. This serialization of feature development ensures that some useful features will be completed even if less work can be accomplished during a Sprint than expected.

 

Waterfall

Waterfall processes are linear. They assume the Project Management Institute’s definition of a project as a “temporary endeavor undertaking to create a unique product, service, or result.” Of course, one can repeat a particular Waterfall process to produce a cyclical “overprocess,” and this is common in the software industry, but a Waterfall process is not cyclical.

In a Waterfall process, the Project Manager works with stakeholders to elicit requirements, and creates a work breakdown structure (WBS) that defines tasks at a granularity suitable for estimation. The development-team members provide estimates for the work, and the Project Manager develops a schedule based on the work estimates, task dependencies, and resources. The project team then executes the work according to the schedule. The Project Manager monitors progress, facilitates problem resolution, and solicits scope or schedule changes as needed to meet the project objectives.

 

Why Choose Scrum versus Waterfall for Software Projects?

The two approaches make different assumptions about the priorities and practicalities of the work to be accomplished.

Waterfall Processes Assume or Require that

• • Success is defined by achieving the planned scope.
    • • Tightest constraint may be on scope or schedule
        • • Sometimes schedule is extended to achieve scope

         

        • • Sometimes scope is reduced to achieve schedule

         

         

     

     

 

• • Requirements are well-understood and will not change
    • • Change requests represent exceptions that must be handled by a change-request process

     

     

 

• • All steps are known and can be estimated with reasonable accuracy

 

• • Process is linear: Starts with requirements, leads to results, and stops

 

• • Some steps may involve long lead times, or lots of specialized resources

 

• • Incremental results (e.g, at 20% of scope) have little or no value

 

 

Scrum Projects Assume or Require that

• • Success is defined by responsiveness to customer requests
    • • Requires quick turnaround (2—4 week Sprints) for high-priority requests

     

    • • Tightest constraint is on schedule, to achieve quick turnaround
        • • Scope is adjusted to fit schedule

         

         

     

     

 

• • Requirements change frequently, even from month to month
    • • Change is the norm, and requests are re-prioritized at Sprint boundaries

     

     

 

• • Work requires constant invention, so all steps are not known in advance, and estimates are not expected to be reliable

 

• • Process is cyclic: It repeats every Sprint, and planning for next Sprint overlaps with the work on the current Sprint

 

• • No steps involve long lead times or lots of specialized resources

 

• • Incremental results (e.g., at 20% of scope) have significant value

 

 

Few of the criteria individually identify which process is more appropriate for a project, but taken together, the decision is usually straightforward. Some examples include

• • Deploying an ERP application, such as SAP. The vendor has done this many times, has a process with all steps clearly defined and understood, and can proceed with a well-practiced waterfall process.

 

• • Creating custom reports for the ERP application. This is likely to be an iterative process, as reports evolve towards greater usefulness over time due to user feedback, and is well-suited to a Scrum process.

 

In general, if you have to figure out how to do a significant amount of the work in the project because you haven’t done it before, so you cannot estimate accurately, go with a Scrum process. If you’ve done it many times before, and know how to do it again, go with a waterfall process.

About the Author

Kevin Thompson, Ph.D., is a Certified Scrum Practitioner and Project Management Professional. His Scrum in Practice workshop through cPrime www.cprime.com trains teams, Program Managers, and PMO personnel on the nuts-and-bolts of how to implement Scrum for software development.

 

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.