How can you go about Optimising Product Delivery? You may think the focus of this article is going to be on how to Manage the Product Backlog? Or maybe how to speed up Sprints? These are necessary activities to deliver a Product. However, the foundations for getting a successful Product are laid long before defining the Requirements. They are also laid long before assembling the Scrum Team (Scrum Master, Product Owner and Development Team) for the Project.

Successful Product delivery depends upon Meeting the Customer’s expectations. This means bug-free Code. It means the Customer gets what they asked for in the very first place.

Optimising Product Delivery: Where it all Starts

So how do we get the expected results? We need to apply the Principles of New Product Development (NPD). We then need to utilize a couple of specifics from Lean Startup theory. This starts with the idea for the new or improved Product. It could be a simple “Lightbulb” idea from one of the executives, or the output from a brainstorming Workshop. In many Organisations, this is enough to get the ball rolling. Unfortunately this is why there are so many Product failures, and a huge waste of money.

Getting Shot down in Flames

Before taking the Product concept forward, it requires to be tested for viability. Many of the Criteria are monetary. This include what the Return on Investment (ROI) will there be and when, and what the capex expenses will be.

The really important questions are about the target Market for the Product. There is a succinct saying “there is a space in the Market, but is there a Market in the gap?”. As this article is being composed, there are mobile app Developments being churned out. These apps will only get a limited number of Customers to download them.

If the Product idea was formulated in an innovation Workshop, hopefully they have also completed the viability checks. If the idea does not pass the Criteria for success, it ought to be shelved right now. This does not mean it can not be re-examined later on; maybe current Technology is just too primitive or expensive now; think of the special effects available to George Lucas for Star Wars in the 1970s.

What Kind of Innovation is this?

This is a very important distinction, and not all Product Development is the same. The levels of Risk needs to be understood up front. The Low Risk Development will be a tweak or upgrade to an existing Product. Such as a quarterly Software Release, or an update to an online Product catalogue. A Medium Risk Development might be a mobile variation of a desktop/laptop application. The Product is not entirely brand-new, but if badly performed could have a negative effect on the Customer experience. There is the High Risk Product. . It is a disruptive innovation that will Change the Marketplace. It is not necessarily new Technology, but is a Game-Changer, such as the iPhone, Uber or a Tesla S Car.

With Low and Medium-Risk Products, it could be possible to move into design and build right away. With High-Risk Products, some form of prototype should be built. This is because there are too many unknowns. This is where the Lean Startup method varies. The prototype will be built and even taken to Market in beta-mode. This is to get a more informed idea of the potential for success or failure. What happens in the Lean Startup is that a model of the brand-new Product is built. This must be the foundation for any significant Agile Development

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

Developing a Minimum Viable Product (MVP) Blueprint.

The MVP is precisely what is required in Agile for the Product Owner to Manage the Product Backlog. An MVP is a stripped-down Product. It is the bare bones of the Product that has simply enough Features to go to Market. It is critical that the Concept of the MVP is set before the Project starts. This will provide the Roadmap for the discovery and writing of the contents for the Product Backlog. It will also assist in prioritizing these contents. It is unavoidable that extra Requirements will slip in during the compilation of Epics, Features and User Stories by the Development Team.

With an MVP as a Framework for the Product, the Product Owner will be able to evaluate whether a Requirement is superfluous or has in reality been overlooked when the MVP was developed (the MVP is not perfect, there are a lot of unknowns). If you use Value Points, or Business Value Points, the MVP is an excellent foundation for Estimating Business Value prior to you begin the Product Backlog.

Optimising Product Delivery: Keeping the Product Optimized

The Product delivery needs to be enhanced on a number of fronts:-.

• Product alignment – does the delivered Product match the User expectations?
• Product Quality – defects need to be reduced and UX must be well designed and aesthetically pleasing.
• Traditional Projects of time and budget must be observed and Managed by means of focusing on the Product Backlog.
• There should always be the possibility to cancel the Project in case of Projected failure, instead of going on a “Death March”.

The Product Owner has a major Role to play in keeping the Project focus where it should be. This begins with handling Stakeholder Requirements and ensuring that the right User stories are composed with input from the key Stakeholders. These are collated and prioritised in the Product Backlog, with priorities assigned according to the MVP. The MVP also streamlines the User Story process, because the Product Owner can identify which Stakeholders must be engaged and which Stakeholders are outside the scope of the MVP.

Optimising Product Delivery: Value Points

Not all Teams use Value Points to describe the progress of their Projects. This is generally because it is quite difficult to designate Value to any item in the Product Backlog. We recommend that you assign them to any Epics and possibly Features. User Stories are too atomic to assign a Value and there is little Value added. The Benefit of assigning Value points is that they quantify progress to Stakeholders in Business terms. It give a better view of the Project status.

Planning a Sprint can be quite a challenge for inexperienced Teams. While the Product Owner has prioritised the contents of the Product Backlog, it is the Team that decides what they want to achieve in a Sprint. The Product Owner can identify the results to a particular degree by giving the highest priority to complex and crucial Stories and Features. These must be Developed first, due to the fact that they bring the greatest Risk and unpredictability. If they are not completed first, the Project might stop working due to the fact that time and budget are exhausted before the critical components are Working.

Optimising Product Delivery: Acceptance Criteria

Ensuring that Development is “Done” is another crucial factor in optimizing Development. This needs stringent and comprehensive Acceptance Criteria. These should be Documented and checked prior to any Code being accepted as finished.

Observance of Agile Ceremonies (if you are following Scrum) is an important element in optimizing delivery. Although Meetings are kept to a minimum, they must not be dropped or deferred, particularly Sprint Planning and Stand-Ups. The Reviews are very important liaisons between the Team and Stakeholders where development is discussed and celebrated.

Optimising Product Delivery: The Optimised Product.

The optimised Product must be an outcome that fulfills and matches the Customers’ expectations as illustrated in the MVP plan. It is a Lean Product, without frills, with exactly the functions and Features required to make it viable. It is delivered swiftly and as cost-effectively as possible.

Is this Lean approach the only way to ensure Project success? Not at all, there are Product Stories out there that break many of the guidelines. However, there is still a critical success factor that applies to all winning Products, the Customer is delighted with the Product and needs no encouragement to adopt it. This should always be the overriding criterion for Product Development.