How can the value of the Project Deliverables be maximised in a Scum Project? For those knowledgeable about Traditional Software Project Management, Scrum might seem Organised Chaos. For a start, how can you have a Project without a Project Manager? Scrum is a Collaborative Effort and lacks the Command-and-Control structure of Traditional Project. Its light and straightforward Framework is exceptionally efficient at taking a Concept and Developing it into a Product. A Scrum Project can be included in a Programme or a Portfolio. This is just as Traditional Projects are grouped this way. Where the main distinction lies remains in the Project Planning and the focus on short-term Goals, rather than a Project completion date.

A Traditional Project is usually Planned against time, with 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, generally as a fortnightly or four-week Event, the focus is on the amount of Work that can be Done and the Value added throughout the Sprint, and not the timeline. As each Sprint is completed, there is an Opportunity for improving the Planning for the next phase.

Project Deliverables and Planning Mechanisms

Project Planning for Scrum is carried out in mandatory Meetings. There are 2 main Planning Meeting types:-.

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

All Scrum Meetings include some element of Planning, so the following Meetings also contribute to the Project Planning cycle:-.

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

While the majority of Meetings held include Scrum Team members only, there are also Meetings that need participation of external Stakeholders. This is to both to get their input to the Project Plan and to provide Deliverables to them.

Planning Roles and the Project Deliverables.

Instead of a Project Manager who produces the Project Plan in a Traditional Project, everyone in a Scrum project provides some input to the Project Plan. Planning is a Collaborative Effort. Due to the iterative nature of Scrum, the Plan undergoes Changes and Refinements as the Project progresses. It is accepted that the Plan is firm for only the current Sprint. The main Role-Players in Scrum Planning are:-.

The Product Owner, who is accepted as the subject matter expert on the final Product and the voice of the customer. He is the steward of the Product Backlog, which contains a breakdown of the Requirements for a successful MVP (Minimum Viable Product). As the Product Owner focuses on the contents of the Product Backlog. They have an impact in deciding the order of Development of the Features and Stories to be Worked on in the existing and subsequent Sprints. Each Sprint has a Sprint Backlog, which is a subset of the Product Backlog; Work products are picked based on greatest priority.

The Roles and the Project Deliverables

The Stakeholders, who shape the frequency of Releases. A Release might be Planned for the end of every Sprint, or may be scheduled for every few Sprints. The agreement on when Releases happen likewise helps determine the perfect length for a Sprint in the Project. The Stakeholders likewise take part in Review Meetings, where alignment with the Requirements is Assessed and possible Changes are identified for inclusion in the next Sprint (no Change requests are considered throughout a Sprint).

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

The Development Team Plan what Work they are to do in the next Sprint, based upon the Prioritized Product Backlog and their Sprint Velocity (quantity of Work expressed as a number of points that can be achieved in one Sprint). They likewise own the short-range Planning, as they each report on their next day’s Planned Work in the daily Stand-Up Meetings.

Planning for Value in the Project Deliverables.

During Project Initiation, once the Project Team has been appointed, the first two Planning Meetings can occur. These 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, giving the Stakeholders some comfort as to when Product Features will be Developed and completed, with the acceptance by all parties that only the first Release has a firm date, and that subsequent dates may Change. The Scrum Team can utilize the Release dates to choose on the perfect length of a Sprint, Say 4 weeks.

The Sprint Planning Meeting is the primary Project Planning Meeting, as it determines the Work content for the next Sprint; each User Story chosen for Development is then broken down into Tasks, which are the fundamental currency of the Project, and are used to report on in the Stand-Up Meetings. The very first Planning Meeting has several unknowns to handle, such as the Velocity (quantity of Work) of the Team and whether the Work chosen for the very first Sprint can be finished in the designated timeframe. Subsequent Sprints will be Refined based on the outcomes of the first Sprint.

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

Planning During the Project.

While Scrum may appear like a free-for-all to the observer, it remains in truth tightly Managed by means of the fifteen minute Daily Stand-Up Meeting. This is a short-term Planning Meeting. The team Review the previous day’s Work and a Plan for the next day’s Work. This ensures that the Sprint does not fall behind.

The completion 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. Change requests to the initial Requirements can now be submitted for inclusion in the next Sprint. There is then the Retrospective meeting. This is a Team Meeting where the success of the Sprint is Assessed and Lessons are Learnt. The lessons are then applied to the next Sprint, thus optimising processes and Teamwork. Once these two Meetings have been held, the cycle can begin 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 as the Project progresses, makes a Scrum project resilient.Any indications that the Project is slipping off the rails can be picked up very quickly and as early as possible.  There are only a few reporting Artefacts used in Scrum, but they lend transparency to the Project. The Scrum Board and Burndown Charts are available for all to see; keeping Stakeholders and other Scrum Teams (in the case of a several 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 ensures good integration and Communication between the Team and their Customers.