Do Agile Scrum Projects conduct Project Planning? For those more familiar with Traditional Software Project Management, Scrum might seem like Organised Chaos. For a start, how can you have a Project without a Project Manager? Scrum is a Collaborative Effort and does not have the Command-and-Control structure of Traditional Projects. Its light and straightforward Framework is very effective at taking a Concept and Developing it into a Product. A Scrum Project can reside in a Programme or a Portfolio. This is just like within a Traditional Project which are organized in this manner. The main differences lie in the Project Planning, the focus on short-term Goals and the Project completion date.

A Traditional Project is usually Planned against time. It will have a specified completion date and interim milestones geared towards the Software Development Lifecycle. A Scrum Project is broken down into Iterations (the “Sprints”). While Sprints are Time-Boxed, usually as a fortnightly or four-week Event, the focus is on the quantity of Work that can be Done and the Value added during the Sprint, and not the timeline. As each Sprint is completed, there is an Opportunity for enhancing the Planning for the next stage.

Planning Mechanisms

Project Planning for Scrum is conducted in mandatory Meetings. There are two primary Planning Meeting types:-.

-‘ Release Planning Meeting’.
-‘ Sprint Planning Meeting’.

All Scrum Meetings include some aspect of Planning. The following Meetings likewise contribute to the Project Planning cycle:-.

-‘ Daily Stand-Up Meetings’.
-‘ Sprint Retrospectives’.
-‘ Sprint Review Meetings’.

The majority of Meetings held include only the Scrum Team members. There are also Meetings that need the involvement of external Stakeholders. This is to get their input to the Project Plan and to present Deliverables to them.

Planning Roles.

Rather than a Project Manager who produces the Project Plan in a Traditional Project, everybody in a Scrum provides some input to the Project Plan. The Scrum Project Plan is a Collaborative Effort. Because of the iterative nature of Scrum, the Plan is subject to Changes and Refinements as the Project progresses. It is accepted that the Plan is firm only for the present Sprint. Future Sprints will change to some degree.

The Product Owner, is the subject matter expert on the final Product. They are the steward of the Product Backlog. The Product Backlog contains a breakdown of the Requirements for a successful MVP (Minimum Viable Product). As the Scrum Product Owner prioritises the contents of the Product Backlog, they are in effect choosing the order of Development of the Features and Stories to be Worked on in the current and subsequent Sprints. Each Sprint has a Sprint Backlog, which is a subset of the Product Backlog; Work items are chosen based on greatest priority.

The Stakeholders, shape the frequency of Releases. A Release may be Planned for the end of every Sprint, or every few Sprint. The agreement on when Releases occur helps to determine the ideal length for a Sprint in the Project. The Stakeholders participate in Sprint Review Meetings. This is where positioning of the Requirements is Assessed and possible Changes are identified for inclusion in the next Sprint. There are no Change requests are considered during a Sprint.

The Agile Scrum Master plays a Facilitation Role, quite unlike the Role of Project Manager. They ensure that the required Meetings are held and Time-Boxes them according to the Scrum practices.

The Scrum Development Team Plan what Work they are to do in the next Sprint. They do this during the Sprint Planning Meeting. This is based on the Prioritized Product Backlog and their Sprint Velocity. The Sprint Velocity is the quantity of Work expressed as a number of points that can be accomplished in one Sprint. They also own the short-range Planning. During this meeting they each report on their next day’s Planned Work in the daily Stand-Up Meetings.

Planning for the Project.

During Project Initiation, and once the Project Team has been appointed, the first two Planning Meetings can occur. These meetings are the Project Release Meeting and the Sprint Planning Meeting.

The Release Meeting includes Stakeholders, and a decision is made on the frequency of Releases. This is very Product and Environment specific and is tied directly to the Sprints. Approximate Release dates are scheduled. This gives the Stakeholders some comfort as to when Product Features will be Developed and completed.

The Scrum Team can utilize the Release dates to choose the perfect length of a Sprint.

We found these books great for finding out more information on Agile Scrum:

The Sprint Planning Meeting is the main Project Planning Meeting. This meeting identifies the Work items for the next Sprint. Each User Story selected for Development is then broken down into Tasks during this meeting. The tasks are the standard currency of the Project, and are used to report on in the Stand-Up Meetings. The first Planning Meeting has several unknowns to handle. These unknowns include the Velocity (quantity of Work) of the Team, the perfect length of a Sprint and whether the Work chosen can be completed in the allotted timeframe. Subsequent Sprints will be Refined based on the outcomes of the very first Sprint.

Planning During the Project.

While Scrum may appear like a free-for-all to the observer, it is in fact firmly Managed by means of the fifteen minute Daily Stand-Up Meeting. This is a short-term Planning Meeting. During the meeting the team Review yesterday’s Work and Plan for the next day’s Work. This makes sure that the Sprint remains on schedule.

The conclusion of a Sprint is followed by two Meetings. The Sprint Review, where Stakeholders are invited to hear and see what was Developed during the Sprint. There is then the Retrospective Meeting. During this meeting the Team Meeting discuss the success of the Sprint, along with the Lessons Learnt. These lessons can then be applied to the next Sprint, thus optimising processes and Teamwork. Once these two Meetings have been held, the cycle can start again, with the next Sprint Planning Meeting.

A Fluid and Agile Plan.

The acceptance by both the Team and Stakeholders that the Planning for a Scrum Project is short-range and subject to Change, makes a Scrum resilient. Any indicators that the Project is slipping off the rails can be identified quickly. There are only a few reporting Artefacts utilized in Scrum. These provide transparency to the Project. The Scrum Board and the Burndown Charts are available to all to see. These keep the Stakeholders and other Scrum Teams (in the case of a numerous Team Project) apprised of where the Project is at any time, along with where it is going. The Release Management of Scrum provides the Stakeholders with the required Deliverables at the right stage of Product Development and guarantees excellent integration and Communication between the Team and their Customers.