How can the Scrum Team go about Optimising Product Delivery in an Agile Scrum Project? You might think the focus of this article is going to be on how to manage  the Product Backlog. Or maybe how to accelerate sprints. While these are required activities to deliver a Product, the foundations for getting an effective Product are laid long before defining the Requirements. They should occur before assembling the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team). Have you ever been involved in a project where the developers are bragging about their low defect score? At the same time what they are delivering bears little relation to the original user specification! Effective Product delivery depends on Meeting the Customer’s expectations. Bug-free Code should be part of the package. However, first prize for the Customer is what they asked for in the 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). After that we need to utilize a few specifics from Lean Startup theory. This begins with the concept for the new or enhanced Product. This might be a simple “Lightbulb” concept from one of the executives, or the output from a brainstorming Workshop. In lots of Organisations, this is enough to get the ball rolling. Unfortunately this is why there are many Product failures, and a substantial waste of money.

Getting Shot down in Flames

Prior to taking the Product concept forward, it needs to be kicked around and tested for practicality. Many of the criteria are financial, such as what return on investment (ROI) will there be and when, and what the CAPEX costs will be. The really important questions are about the target Market for the Product.

There is a succinct saying “there is a gap in the market, but is there a market in the gap?”. As this is being written, there are mobile app developments being churned out that very few customers will bother to download. A case in point is an app that reminds you to renew an annual subscription (and there are plenty of them).

If the product idea was formulated in an innovation workshop, hopefully they have also completed the viability checks. If the concept does not pass the Criteria for success, it should be shelved right away. This does not mean it can not be re-examined later; possibly current Technology is simply too primitive or pricey 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, not all product development is the same, and the level of risk needs to be understood up front. The Low Risk Development will be a tweak or upgrade to an existing Product, like a quarterly Software Release, or an upgrade to an online Product brochure. A Medium Risk Development could be a mobile version of a desktop/laptop application, the Product is not completely new, however if badly carried out might have an unfavorable impact on the Customer experience. There is then 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 might be possible to move into design and build right now. With High-Risk Products, some form of prototype ought to be integrated in an incubator or laboratory. This is due to the fact that there are too many unknowns. This is where the Lean Startup method differs, because the model will be constructed and even taken to Market in beta-mode, to get a more informed idea of the potential for success or failure. What happens in the Lean Startup is that a design of the brand-new Product is built. This must be the foundation for any significant Agile Development.

Optimising Product Delivery: Producing a Minimum Viable Product (MVP) Blueprint.

The MVP is precisely what is required in Agile Projects. The Product Owner Manages the Product Backlog with this in mind. An MVP is a stripped-down Product, the bare bones of the Product that has just enough Features to go to Market. It is vital that the Concept of the MVP is set prior to the Project beginning. This will provide the Roadmap for the discovery and writing of the contents for the Product Backlog. It will also help in prioritizing these contents.

It is unavoidable that extra Requirements will slip in throughout the compilation of Epics, Features and User Stories by the Team. With an MVP as a Framework for the Product, the Product Owner will be able to assess whether a Requirement is necessary. If you utilize Value Points, or Business Value Points, the MVP is an excellent structure for Estimating Business Value prior to starting the Product Backlog.

The Agile Project has actually Started: Keeping it Optimized

The Product delivery needs to be optimized on a variety of fronts:-.

• Product alignment – does the provided Product match the User expectations?
• Product Quality – defects should be minimised and UX should be well created and visually pleasing.
• Traditional Project metrics of time and budget need to be observed and Managed by means of prioritizing the Product Backlog.
• There ought to constantly be the possibility to cancel the Project in case of Projected failure, rather than 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 managing Stakeholder Requirements and ensuring that the best User stories are written with input from the key Stakeholders. These are collated and prioritised in the Product Backlog, with priorities assigned according to the MVP. The MVP likewise streamlines the User Story process, because the Product Owner can recognize which Stakeholders needs to be engaged and which Stakeholders are outside the scope of the MVP.

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

Optimising Product Delivery: Value Points

Not all Teams utilize Value Points to explain the progress of their Projects. This is primarily due to the fact that it is rather difficult to designate Value to any item in the Product Backlog. It is recommended that you assign them to Epics and Features. User Stories are too atomic to designate a Value and there is little Value added. The Benefit of assigning Value points is that they quantify progress to Stakeholders in Business terms, and offer 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 chooses what they can achieve in a Sprint. The Product Owner can determine the outcomes to a specific extent by providing the greatest priority to complex and critical Stories and Features. These should be developed first, because they carry the highest risk and uncertainty. If they are not completed first, the project could fail because time and budget are exhausted before the critical components are working.

Ensuring that Development is “Done” is another critical factor in optimising Development. This requires that stringent and comprehensive acceptance criteria are documented and checked before any code is accepted as completed.

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

Optimising Product Delivery: The Optimised Product.

The optimised Product must be a result that satisfies and matches the Customers’ expectations as highlighted in the MVP plan. It is a Lean Product, without frills, with precisely the functions and Features needed to make it practical. It is delivered quickly and as cost-effectively as possible. Modern Business Changes too quickly to cater for 5-year Development Projects.

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

Is this lean approach the only way to ensure project success? Not at all, there are Product Stories out there that break most of the rules. However, there is still a critical success factor that applies to all winning Products, the Customer is happy with the Product and needs no encouragement to adopt it. This must constantly be the overriding requirement for Product Development.