Envisioning (Planning) Agile Product

Each and every new product needs to be improved and built with a new innovative thought. Envisioning is nothing but the planning activity done for the product to support organizations which describe the plan and design a blueprint for how to follow its creation.

An Overview

Product Planning is a lightweight process of Scrum. Its overall goal is to move from the guessing stage as soon as possible. The ‘guessing stage’ is a stage from where organizations know the needs of the customer and the potential solution, as the input to the ‘fast feedback’ stage. The purpose behind using the envisioning process is to produce 3 key segments of data, as follows:

1. Keep the vision towards the product
2. Adequate information to know about the features, high-level conclusion, and the Stakeholders
3. Estimate the cost of the product.

With the help of these points, organizations can plan their investments for the future phases of product development.

Duration

Scrum is a continuous process and not a single time event for envisioning the products. Not only are the newly added or improved ideas are updated in the process, but the products are also clearly examined through the process of envisioning as well. In this manner, after moving to the first envisioning phase, succeeding envisioning stages will probably be conducted to explain whether to move with the initial view, try to achieve a new goal-turn, or close the project.

Participants

At the beginning of envisioning a Scrum product, the important member is the Product Owner. Generally, the Product Owner interacts with one or other internal customers, user experience design, development of business case, experts in marketing research, and planning the systems.

The image below indicates the Scrum process.

It is not mandatory that the Scrum team members should be present during the envisioning process. This results in reality that, during early envisioning, a Scrum team might not yet be funded. During product development, or anytime a full Scrum team is available to lend insight and technical expertise, the Scrum team should be included.

Process in Scrum

During product development, important data could be the pivoted concept. A pivoted concept in the Scrum process is a plan that has made required changes according to the user or the stakeholder’s feedback, unstable moves by opponents, funding changes, or some other significant changes that might happen within the complicated environment where ideas must exist.

However, all these could not be the inputs to the envisioning product in Scrum. Companies should also know the following stages:

1. Planning horizon: Consider how far into the future
2. Date of completion for product-forecasting
3. The kind of sources and quantity accessible to operate the product envisioning
4. Confidence threshold: A set of lines of data that the decision makers requires in order to plan a decision towards a goal

There are many different activities required for the product Envisioning in Scrum, each producing important deliverables. Those are product roadmap (optional), product vision, or the initial product backlog. Companies should also accomplish any other activities that are required to reach the goal with a confident approach in a commercial way.

What is Product Vision In Scrum?

An idea of developing the new product should represent the creation of an effective vision by organizations. The product vision in Scrum is a short description of the resultant future that could be acquired by deploying and developing the product. The focus should be very simple and offer clear instructions to the users who are requested to recognize it.

Let’s consider an example of Kennedy's vision to describe a good product vision to reach to the satellite: “I trust that this world should have a commitment towards achieving the aim before the period of time is out in alighting a gentleman on the satellite and return back him to earth safely.” in the above lines, Kennedy was about to show aggression with a clear focus to be attained, and could ultimately require the actions of lots of people grouping together to build several compound systems with millions of corresponding components.

If you are planning to develop the services or products, many ideas are expressed from the point of customer value. This might mean everything starting from being on equal terms with competitors or increasing the equivalence bar, to reassign the game by changing market focus, reduce the market time, or target a new market.

Most of the standard vision formats are found by Jim Highsmith’s in the year 2009 for Agile Product Management: Creation of innovative products, which includes

1. User conference slides: Have two to three presentation slides that will help in introducing the product at a user conference. Avoid bullet points.
2. Press release: Write a one-page press release describing ‘what’s new’ in the new product being introduced.
3. Product datasheet: A one-page marketing piece.
4. Product vision box: Illustrate the box the product might ship in, including three to four points to emphasize on the label.
5. Elevator statement: A quick pitch of the product vision lasting from thirty seconds to a minute’s time.
   

How to Create a High-Quality Product Backlog

In the beginner's level, the product backlog for an envisioned product should be of high standards. They expressed in terms of the user story, that means the items in the product backlog should be epics of really large user stories that aligned with the product vision and give the future level of product details for higher management and the Scrum team.

Definition of Product Road Map

Once, the primary product vision and a high-quality product backlog are created, multiple organizations select to describe a product roadmap with a small series of recurrent, incremental releases to complete a few or all of the product vision. These product roadmaps are defined below.

1. Minimum Releasable features (or)
2. Minimum Marketable Features
3. Minimum Viable Products

In the product roadmap, each and every incremental release should be focused on a tiny set of minimum releasable features (MRFs) through which the customer group shares a strong agreement among them.

Minimum Marketable Features (MMFs) or Minimum Releasable Features (MRFs)

Minimum Marketable Features(MMF) are the smallest segments of functionality that can be delivered with its significance to both the organizations in bringing and the users using it. An MMF is a part of both an MMP or MMR.

Once the products are successfully developed, they are deployed gradually into the production phase, with each deployment being referred to as an important release. An MRF is the outcome of a product, one that has a set of smallest possible features that give the current requirements of our stakeholders.

The main advantage of MRF is used to decrease the market time between the product releases by reducing the coherent set of features for each release to a small increment that produces new deliverable value to the end users or the stakeholders.

Minimum Viable Products (MVPs)

The minimum viable products(MVPs) is one of the versions of a new product that is constructed with less possible efforts to be used for verifying the stakeholders. The MVPs are used in running the experiments to study the theory about what the users or stakeholders really need. They are very close to the standards that they are to the actual running version of the shippable product.

A development team members usually deploy the viable product to a subset of our stakeholders to test with a new concept, and gather information about it, and thereby know from it. These are created to support you in finding the requirements that the stakeholders or users actually needed it.

How the Product Roadmaps Acquire-Release Goals?

The product roadmap should have a clearly defined release goal in order to deliver a product successfully. A release goal discloses the desired deliverable of the release and its purpose.

Generally, release goals depend on the factors that organization finds relevant to specify the target set of releases, including the target stakeholders or users for that specific product outcome, valued marketplace events, high-level architectural problems, and so on.

What needs to be kept in mind is that the product roadmap is a rough calculation of one or more releases. It should not predict further, because too much looking forward might change the product roadmap. The product roadmaps should be improved with the information that becomes available.