Traditional Waterfall Vs Scrum Project

ITEM	TRADITIONAL WATERFALL	SCRUM
Processes
Project Planning (Scope, Schedule, Communication, and Human Resources)	. There is no equivalent of a Vision statement in waterfall projects, although a corporate Strategic Directive may be derived to specify direction and ultimately the projects that support it. . There is no specific equivalent of a Roadmap in waterfall projects, although companies may generate their own internal Strategic Plans in support of Strategic Directives. . Once a project has been justified and approved, the PM leads the requirements gathering and time estimation effort by holding extensive meetings with Business Analysts, designers, architects, IT, Product Owner(s) and key stakeholders. The PM oversees the creation of documentation-related deliverables such as Feasibility Studies, Statements of Work, Communication Plan, Contracts, Requirements Documents, etc. . The PM creates the Project Plan to derive a preliminary project schedule and subsequently baselines the plan after reviewing it with project team members and management. . The PM meets with the project team periodically (as specified within the Communication Plan) to update the Project Plan with actual hours and revised estimates, and to discuss risks and/or issues. The PM is chartered with documenting risks and issues and overseeing their successful closure. . Line Management decides upon project team resource allocations. The PM may negotiate with management at any time for resources if available resources are insufficient to deliver the project scope within the prescribed schedule. . The project is usually end date-driven and generally incorporates as many requirements as possible.	5 Levels of Planning: . Vision (a brief statement specifying direction) derived by Product Owner . Roadmap (a brief document consisting of 1 year’s worth of high level features) created by the Product Owner & Executives . Release Plan to deliver larger initiatives across multiple Sprints, compiled by the Product Owner and Development Team. The effort is usually facilitated by the Scrum Master. . A Sprint Plan identifying all tasks & estimated task hours is created by the Product Owner & Development Team – not by the Scrum Master. It is updated daily by the team at the Scrum meeting once the Sprint commences. Only estimated hours outstanding are tracked – actual hours are neither requested nor recorded. . Daily Sprint Meeting or Scrum. (15 min.) which is facilitated by the Scrum Master. This is the main means of ongoing team communication. The Scrum Master asks each team member what was committed to yesterday, what is being committed to today, and if there are any obstacles. The Scrum Master records obstacles and oversees their removal. The Sprint Plan is updated with estimated hours outstanding. . Line Management allocates Sprint resources. Negotiation prior to the beginning of the Sprint may or may not be possible, depending upon corporate adaptation of Scrum. Scrum team composition does not change during the course of the Sprint. . Project schedule is derived via the Release Plan if appropriate. Each Sprint is of fixed duration, and the highest priority items are delivered in the initial Sprint(s).
Monitoring Project Change Control and Risk – (Scope and Risk)	. Changes to requirements are typically managed through a Change Control Process overseen by the Project Manager. Activities include sizing, and obtaining management approval. . The Project Manager is responsible for Risk Analysis and Contingency Planning, and usually maintains and publishes a Risk Document.	. Only the Sprint team can change features and tasks within a Sprint, and only if jointly agreed by all members of the Sprint Team. Otherwise the requested item is added to the Product Backlog. . The team performs risk management activities before starting development work. Risk may be discussed during Release, Sprint Planning, and/or daily Scrum Meetings.
Task Ownership; Actuals/Estimates (Schedule and Human Resources)	. The PM creates a Project Plan with tasks, assignments, and estimated hours. The Project Plan is reviewed with the Project Team and base lined once all parties concur. Deviations from the baseline must be explained and addressed by the PM. . The PM periodically updates the Project Plan with actual hours and new estimates, as well as with additional tasks based upon team input. . The PM acts as a coach and leader for the project team and assists team members in overcoming obstacles.	. Team members create, sign up for, and estimate tasks in lieu of being assigned to tasks by the Scrum Master. There is no baselining in Scrum. . Team members may adjust estimated outstanding hours and add, transfer, or cancel tasks during the daily Sprint Meeting. Actual hours are not tracked – only hours outstanding. . The Scrum Master facilitates the team but typically does not coach or lead team members, who are considered self-managing.
Project Overruns (Schedule)	. If the completion date of the project or phase appears to be in jeopardy, the PM is responsible for negotiating one or more of the 5 following items: • Scope (reduction) • Schedule • Cost • Resources • Quality	. Scrum promotes a fixed 30 day timeframe for deliverables. If it appears that a deliverable(s) may be delayed, the item(s) will be added to the Product Backlog and will most likely be carried forward to the next Sprint. The Sprint itself is never extended, nor does the Scrum Master negotiate for additional resources or time.
Project Budget (Cost)	. Typically, a project must provide ROI in order to be launched, at which point a Project Budget is derived. . The PM usually manages the Project Budget, which includes resource costs, technical costs, consultancy, departmental charge backs (if appropriate), and other expenses. Potential overruns must be justified and approved, and/or the PM must negotiate adjustments to the aforementioned 5 items in order to meet budget.	. At the beginning of each Sprint, the Product Owner may be asked how much they want to spend on the Sprint. Based upon the answer, the team may use cost as a guideline when selecting an appropriate amount of work from the Product Backlog to be done in the Sprint. . No mention could be found in Scrum materials regarding Sprint-related budgets. It is assumed that each corporation adopts its own practices with respect to software development costs.
Project Control – (Quality)	. From the customer’s perspective, quality means on-time system delivery, to spec, and within budget and schedule. . Quality Management Plans and Checklists are often used to document and cross-check quality requirements. Although the PM might not be personally accountable for drafting these, s/he is responsible for ensuring that quality requirements and metrics are actualized by the project. . In waterfall projects, QA personnel typically become engaged in the testing phase.	. In Scrum, quality entails the delivery of a working product increment by the end of the Sprint in accordance with the specified feature(s). In cases where expense is a factor, cost constraints must be adhered to as well. . When applicable, quality-related features may be identified in Release and/or Sprint Planning Meetings, and they are built during the Sprint. As with any other feature, the entire Sprint team is accountable for providing the quality feature. . In Scrum, QA personnel may be needed for testing in every Sprint, which can create a resource burden on this group.
Documents
Cost Benefit Analysis	. A Cost Benefit Analysis (CBA) may be submitted and approved in order for a project to be done. The PM may or may not be chartered with compiling this document. ROI is typically a key factor with respect to whether an initiative is approved for development.	. The author could not locate a CBA equivalent in Scrum.
Requirements	. Related documents include but are not limited to: * Feasibility Study * Statement of Work * Project Scope *. Requirements Document * Functional Design * Detailed Design * Test Plans and Test Cases, which are sometimes done at the Requirements Definition Phase . The PM is generally chartered with overseeing that the necessary requirements-related documentation is compiled and approved.	. In Scrum, there are 3 requirements-related items: * Product Backlog * Release Plan * Sprint Backlog/Plan . All three items are compiled by the Product Owner and Development Team, although the Scrum Master may facilitate the meetings.
Change Control	. PM is accountable for overseeing that changes to original project scope are documented, submitted, and approved.	. Once a Sprint is underway, the entire team must concur upon a change before it is accepted. Other changes may be added to the Product Backlog at any time.
Communication Plan	. PM compiles and disseminates a Communication Plan depicting project communication-related deliverables (such as Team Meetings and Steering Committee Status Reports), specifying who will receive or be involved in them, and how often.	. There is no equivalent to the Communication Plan in Scrum.
Budget Spreadsheet	. Generally the PM is accountable for overseeing and reporting the Project Budget.	. The author could find no mention of Project Budget maintenance with specific respect to Scrum.
Issues Log	. The PM is accountable for compiling and updating the Issues Log and for overseeing that issues are resolved.	. Issues/obstacles can be raised at any point, and the Scrum Master is responsible for documenting them, removing obstacles, and overseeing their closure.
Risk Analysis	. The PM is accountable for compiling and updating the Risk Analysis and Contingency Plan, and for navigating the team safely through the risks in order to deliver the project successfully.	. Risks are documented by the Product Owner and Development Team in the Release Plan. The entire Sprint Team is responsible for resolving risks throughout the Sprint.
Project Plan	. The PM uses the Project Plan to derive the preliminary project schedule. The PM then baselines the schedule and meets periodically with the team to update the Project Plan with actual hours and revised estimates/tasks.	. The Sprint Plan (tasks & hours per Sprint) is created by the Product Owner &Dev Team – not by the Scrum Master. It is updated daily by the team once the Sprint begins. Only estimated hours outstanding are tracked. The Sprint Plan is not baselined.
Status Reports	. The PM generates and delivers Project Status Reports as warranted.	. Scrum does not specifically address project status reports. Scrum is generally light on documentation; it emphasizes personal interaction which would normally entail status-related information.
Quality Management Plan; Checklists	. Quality Management Plans and Checklists are often used to document and cross-check quality requirements. Although the PM might not be personally accountable for drafting these, s/he is responsible for ensuring that quality requirements and metrics are actualized by the project.	. When applicable, quality-related features may be identified in Release and/or Sprint Planning Meetings and built during the Sprint. As with any other feature, the entire Sprint team is accountable for providing the tasks and activities to support quality-related items.
Test Plans	. Although the PM may not actually write test plans, the PM is responsible for ensuring that test plans are documented and successfully deployed.	. Scrum acknowledges that a viable product increment must be delivered and accepted in a Sprint. It is up to the Product Owner to determine and ultimately test for viability within the Sprint.
Post-Implementation Support	. The PM is responsible for ensuring that post-installation support is available to the product recipient.	. A “stabilizing Sprint” may be planned for in the Release Plan and executed where  appropriate.
Team Meetings
Steering Committee Status Meetings	. For high-visibility, high-risk endeavors, the PM will set up and participate in regularly scheduled Steering Committee Meetings (as per the Communication Plan) at which the status of the project is discussed.	. The author could find no mention of Steering Committee Meetings with respect to Scrum.
Team Meetings	. As per the Communication Plan, the PM will usually schedule regular team meetings to discuss progress, actuals/estimates, issues, and risk. Such meetings may last an hour or more.	. In Scrum, the 15-minute daily Scrum meeting is the key vehicle for discussing progress, roadblocks, and upcoming commitments as well as obstacles.
Post-Implementation Review	. There is no equivalent to the Sprint Demo in traditional waterfall projects. . It is common for the PM to hold a Post Implementation Review with the Project Team at the end of the project in order to document what went well and what could be improved upon.	. At the end of each Sprint, a Demo is held at which the product recipient demonstrates the usable product increment created during the Sprint. . A Retrospective is held, at which team members reflect about the past Sprint and make recommendations about future improvements or changes. The Scrum Master typically hosts the Retrospective.