What is the Scrum Project Plan and what role does the Product Owner play? Planning for a successful project occurs long before the individual user stories are written. It begins with the Scrum Team selection and the roles and responsibilities of the team members. The Product Owner (the Voice of the Customer) must be immersed in the Project. They should not be subject to outside interference. Without these safeguards in place the project could fail. This can occur no matter how experienced the Development Team is. The essential reason for this is that the Product Owner has the best understanding of the Company Environment. They have the clearest Vision of how the new Product will fit into that Environment.

Scrum Project Plan: The Product Owner Responsibilities

The Product Owner has the Responsibility for delivering a successful Product. They can achieve this by scrupulous attention to the Product description. The product description is housed in an Artefact called the Product Backlog. The Product description differs from the Traditional Business Requirements Document. All of the aspects of the Product are Documented as “User Stories”. User Stories are atomic descriptions of an aspect of the Product that are expressed from the viewpoint of the User.

A typical User Story would be “I Want To Access The System so that I can achieve something…”. This described how the User visits to the application and their reason for doing so. The User Stories are preceded by “Epics” which are more comprehensive descriptions of what the Product ought to do. “Features” are descriptions of specific attributes of the Product. Additional Items that expand on the User Stories and Product Features are also stored in the Product Backlog. The Product Backlog is prioritised based on the significance to any particular Epic, Feature or User Story.

Scrum Project Plan: Picking the Product Owner

When selecting the Product Owner, you should bear in mind that this will be a job for the entire Project. They are “on leave” from their normal job and all effort should be taken to ensure this remains the case. The reasons for this is:-.

• They require to dedicate to the Project and can not be side tracked by other tasks. If the requirements on their time from the Business system end up being too intrusive, the Scrum Master can intervene. The Scrum Master can escalate this issue to whatever level is required to reduce the disturbance.
• They must have a good understanding of the Company, its Culture and Processes. There should be an understanding of any history appropriate to the new Product and the Project. This consists of a capability to co-opt the right person at the right time to supply the content for an Epic, a Feature or a User Story.
• They must have a great eye for detail to ensure User Stories are aligned with the Project. There should be an ability to analyse what the critical success elements are for the Project. Every piece of Work has to be examined and agreed according to a set of Acceptance Criteria. Their Role in this is essential.

• They must be decisive and firm. The decision-making capability will be used in Prioritisation of the Product Backlog. The Product Owner has the right to halt or even cancel the Project.

• They need to be an extrovert and a good Communicator, who infuses the Scrum Team with enthusiasm. Being a great Team player is not a prerequisite, however they ought to be a democrat and not a dictator.

It might be challenging to discover the exact fit for the Role. There will often be a couple of individuals who match the profile.

Smoothing the Way Forward.

The Project is about the Product development. The Product Owner arrives at the Project informed and knowledgeable about the new Product. This suggests their involvement starts at Product Conception.

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

Scrum Project Plan: Before the Project Starts.

In order to get the right Product to Market in the fastest time, the Product Concept and what it involves must be discussed and validated. The output is a Minimum Viable Product (MVP), which is a description of What the Product is, What it is Not, and the Minimum Feature set needed to release a successful Product. Naturally, the Product Owner needs to be included in this process from creation, so that they can bring the Vision through to the Project and the Development Team.

Scrum Project Plan: The Project Starts.

Preferably the Scrum Team must be located in an area of their own. They are going to work in close Collaboration and need to be close and not spread around the building. This will likewise reduce the chance for interruptions and distractions. They need to be available for the Development Team to bounce concerns off them. Sitting with the team makes this a much easier task. The Scrum Project begins with the Team being created and presented to each other. It is followed by the first Sprint. This is where the Product Owner asks the Scrum Master to convene a Project Planning Meeting.

Scrum Project Plan: Throughout the Project.

The Product Owner is the keeper and the person who Prioritizes of the Product Backlog. This is a continuous task, as priorities will Change with each Iteration, or Sprint. They will also inspect what the Team considers to be a finished Work item. After reviewing the deliverable they determine whether all the Acceptance Criteria have been met. If all criteria are satisfied, the Work is “Done”. When all sprint deliverables are complete, the Product Owner calls for a Review Meeting. At this meeting the results of the Sprint are Communicated to the Stakeholders and any other interested Parties.

On Completion.

When the Project is completed and the Product is delivered, the Product Owner can return to their normal Work. The difficulty is that a really successful Product Owner is probably more Valuable to the Company in the Product Development sphere than in his selected job.

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

The Successful Product Owner.

The successful Product Owner is totally committed to the Project. Their autonomy and authority is identified by all the Stakeholders and not lessened by commands and disturbance from outside the Project.

The Product Owner both orchestrates and adds to the definition of the Product. They do this by either co-opting the appropriate subject matter experts to supply Epics and User Stories, or by offering such details directly, based on their own experience. By prioritising the contents of the Product Backlog (the User Stories), they could be regarded as the editor of an anthology of short Stories about the Product, which, when read in their entirety, reveal the complete Product. Their guidance throughout the Project and each Sprint will enable the Team to produce the best possible Product that meets the customers requirements.