scrum

For those of you familiar with a traditional project management process, you’re probably familiar with a typical project life cycle- plan, budget, design, develop, test and release, AKA waterfall. This style of management can typically be found in fixed-bid projects. You may be less familiar with the percentage of projects that utilize this management process, yet fail to stay within the project’s intended time line, budget and scope.

According to the “Chaos Report”, a project management study on software development companies:

…35 percent of software projects started in 2006 can be categorized as successful, meaning they were completed on time, on budget and met user requirements. This is a marked improvement from the first, groundbreaking report in 1994 that labeled only 16.2 percent of projects as successful…

35 percent! Almost two out of every three software development or integration projects are failures. If you are not planning on selling services or merchandise on your site, collecting customer data or statistics, or updating site content via a content management system, you can probably rest assured your project will not be a total failure. However, if you are planning on utilizing any or all of these features into your website, I highly recommend you continue reading.

In the Scrum process, the Sprint Retrospective Meeting follows the Sprint review meeting. At this time-boxed 3 hour meeting, the ScrumMaster encourages the Team to revise, within the Scrum process framework and practices, its development processes to make it more effective and enjoyable for the next Sprint.

Further Reading

In the Scrum process, the Sprint Review Meeting is held at the end of each Sprint cycle. It is a 4-hour time boxed meeting at which the Team presents what was developed during the Sprint to the Product Owner and any other stakeholders who want to attend. This informal meeting at which the functionality is presented is intended to bring people together and help them collaboratively determine what the Team should do next.

Further Reading

In the Scrum process, the Sprint Backlog defines the work, or tasks, that a Team defines for turning the Product Backlog into an increment of potentially shippable product functionality.

Tasks should be divided so that each takes roughly 4 to 16 hours to finish. Tasks longer then 4 to 16 hours are merely placeholders for tasks that haven't yet been appropriately defined. Only the Team can change the Sprint Backlog.

Further Reading

In the Scrum process, the Sprint is the name for the process where work is accomplished. A Sprint is a 30-day iteration in which the Team works to complete new functionality from the Product Backlog. Each Sprint is initiated with a Sprint Planning Meeting and ends with a Sprint Review Meeting.

Further Reading

In the Scrum process, the Daily Scrum Meeting is a 15-minute status meeting during a Sprint cycle. Meetings are led by the ScrumMaster.

Purpose:

To synchronize the work of all Team Members daily and to schedule any meetings that the Team needs to forward its progress.

Time & Location:

The Daily Scrum meeting is time-boxed to 15 minutes regardless of the number of Team Members.

Daily Scrum meeting will be held in the same place at the same time every work day - ideally first thing in the morning.

Attendance:

In the Scrum process, the Sprint Planning Meeting initiates each Sprint cycle. Sprint planning meetings cannot last more then 8 hours, and are broken up into two 4 hour sessions. The first 4 hours are spent with the Product Owner who presents the highest priority product backlog to the Team. During the second 4 hours, the Team plans out the next Sprint. When the second 4 hour meeting commences, time begins to advance for the current Sprint session.

Further Reading

In the Scrum process, the Product Backlog is usually a constantly changing list of prioritized requirements for a project. The Product Owner is responsible for the contents, prioritization, and availability of the Product Backlog.

Further Reading

In the Scrum process, the Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting system. He/she creates the initial overall requirements, ROI objective, release plans, and prioritizes requirements.

Further Reading

A ScrumMaster is the person responsible for the Scrum process, its correct implementation, and the maximization of its benefits.

Further Reading