Incremental Improvements

This Toolkit for Incremental Improvements provides example checklists and questions to help you deliver value rapidly to end users. This will allow you to respond to the feedback you’ve been collecting, but strive to do this by providing frequent, rapid updates to the end user (even if they are small), and maintaining a high velocity, ongoing improvement cycle. In this chapter we will discuss further tips and practices for managing your backlog, effective prioritization and review, discuss your delivery process, and finally close with important Governance considerations. Refer to the supporting material around both the key Roles and Responsibilities and Application Matrix which will be referenced throughout the guidance.

The outcome of this stage should be an updated no-code app based on a focused set of the feedback defined in the last stage. While the application in this stage will continue to evolve, in this stage you are starting the on-going cycle of incremental value delivery that will help you deliver on your stakeholder expectations.

The inputs from the MVP Go-Live release and the feedback collected from stakeholders and feedback channels will form the key inputs into this current effort. Here are a set of key pre-requisites you should make sure are in place before starting this stage.

• Application MVP deployed to production

• Feedback collection (user & system) processes in place

• Continuing support from IT/Ops for Governance reviews and updates

• Continuing Change Management and Backlog processes in place

• Continuing Testing approach and resources (e.g. manual, automation, etc)

• Continuing Work management processes (e.g. Kanban) in place

The work in this stage will be mostly focused around hands-on use of the no-code development tools. As with the previous development stages, it is essential you have resources trained in your no-code vendor’s platform available to support the evolution of the application. It’s not uncommon for the original core no-code team to get focused on other business priorities or new apps, which can reduce the capacity you have for on-going improvements. You may want to supplement your initial no-code team with additional resources (internal or external), to ensure you can maintain a velocity of on-going updates and support.

The first essential step is to make sure you have properly reviewed, refined, and scoped the items in your backlog – this is sometimes referred to as backlog ‘grooming’ by Agile methodologies. This is important to ensure that the backlog is well-maintained, up-to-date, and properly organized for the no-code team to start developing against.

During backlog management sessions, the team collaboratively examines and discusses each backlog item. The goal is to gain a shared understanding of the requirements, break down larger items into smaller, actionable micro use cases/tasks, and estimate the effort needed to complete each item. This process helps ensure the backlog is refined and prioritized based on the team's current understanding, emerging insights, and changing business needs.

Keep in mind the backlog is dynamic – in addition to the original list of features left-over from the MVP release, you’ve now gotten new feedback which must also be assessed. Backlog management therefore involves updating the backlog with new items, removing or re-prioritizing existing ones, and adding details or acceptance criteria to enhance clarity. The refined backlog items that meet the team's ‘Definition of Ready’ are considered ready for implementation in upcoming iterations.

Finally, by regularly grooming the backlog, the team can maintain a well-organized and manageable backlog, reducing ambiguity, minimizing surprises, and enabling smoother no-code development. It helps ensure the entire team remains aligned, maximizing their productivity and delivering value to the stakeholders more effectively.

Here is a suggested framework for establishing an effective backlog management process.

• Evaluate feedback: Refer back to the prior Stage (Feedback Collection), for guidance on evaluating feedback. Analyze the feedback you’ve collected to ensure users are sufficiently documenting their responses so that it's clear and reproducible.

• Identify/refine new features: Based on the feedback, the team identifies features that need to be added which align with the business use case vision/goals. Decompose into as fine a granularity as possible to be more agile about applying changes into the live app, and also help minimize the dependencies.

• Prioritize features: This involves prioritizing based on their value to the customer, business goals, and impact on the business use case. We will discuss prioritization in more detail in the next sub-section in this chapter.

• Define the feature scope: Next, identify the necessary no-code capabilities, reusable components, or custom elements. Refer back to Stage 2 (Options Analysis), as new requirements may necessitate reassessment of the overall architecture.

• Estimate effort: For each of the in scope items, you should estimate the work. Refer back to Stage 4 (Project Assignment), which covered estimation in depth. The guidelines and estimating factors can be reused; however, keep in mind that as you are building more experience in no-code delivery, you should be tracking actuals of your team and using this to help refine the estimating factors.

• Define acceptance criteria: Define conditions that must be met for the feature to be considered complete. This may take clarification with the original source(s) of the feedback, and should be defined based upon input from SMEs and/or your No-code stakeholder.

There is rarely an abundance of time, resources, or budget when it comes to development – instead you will be asked to deliver everything all at once, with fewer resources. Effective prioritization techniques provide structure and guidance in no-code development, enabling teams to focus on the most important and valuable aspects of a project. By making strategic decisions about what to work on first, teams can improve efficiency, meet user needs, mitigate risks, accelerate time-to-market, enhance collaboration, ultimately leading to successful and impactful releases.

It’s highly recommended therefore to adopt a structured approach to prioritization. There are a variety of popular prioritization techniques, including stack ranking, RICE, Cost of Delay, Kano, and the MoSCoW model (amongst others). In this chapter we will briefly discuss MoSCoW which is an effective and commonly used prioritization technique which helps stakeholders categorize and prioritize requirements based on their importance and urgency. We’ll just define MoSCoW and provide an example, but there are numerous online resources that can provide more details and support for applying this prioritization technique in practice.

MoSCoW is an acronym that stands for:

• Must Have: These are critical requirements necessary for the app/project success. They represent the core functionality or features that must be implemented. If any of these requirements are not fulfilled, the app/project viability may be compromised.

• Should Have: These requirements are important, but not as critical as the Must Have ones. They enhance the project's value and may significantly contribute to its success. If feasible, these requirements should be included, but their absence would not jeopardize its overall functionality.

• Could Have: These are desirable requirements that would provide additional value if implemented, but their absence would not impact the core functionality or success. These requirements are considered as optional and can be deferred to a later iteration.

• Won't Have: These requirements are explicitly excluded from the current scope. They are acknowledged as being beyond the current constraints, resources, or time frame. These requirements may be considered for future versions or projects.

Let’s review a quick example of MoSCoW for a digital banking application.

Category	Feature	Rationale
Must have:	User registration and login functionality Account balance and transaction history Fund transfer between accounts Bill payment capabilities	These address the essential features that are crucial for users to perform basic banking tasks and are fundamental to providing a functional banking experience.
Should have:	Mobile check deposit feature Transaction alerts and notifications Personalized budgeting and expense tracking tools Ability to set up recurring payments	These features enhance the core user banking experience and are important for improving user satisfaction and engagement.
Could have:	P2P (person-to-person), payments Cardless ATM withdrawals Integration with third-party financial apps Advanced security features like biometric authentication	These features are desirable and can provide competitive advantages for the bank in the marketplace and may also differentiate the user experience.
Won't have:	Investment and wealth management features Foreign currency exchange services Virtual credit card generation Mortgage and loan application processing	These features are deliberately excluded from the current scope due to resource limitations or the need for further development. They require specialized expertise, additional integrations, or significant development efforts, and may be deferred to future releases.

In addition to MoSCoW, you should find ways to quantify the return on investment (ROI). ROI is a crucial factor when it comes to prioritization, as it helps organizations make informed decisions about resource allocation and helps you allocate resources to Change Requests (CRs), that are expected to deliver the best returns. For larger changes it also helps in evaluating the risk-reward ratio of different options; by factoring in the risks and uncertainties associated with a potential CR, you can make more informed decisions and prioritize one with a higher chance of success. However, it’s not always easy to quantify ROI (especially on more granular CRs), so you may need to find other ways to determine the overall business value/impact the CR may have on the business.

It's worth observing prioritization is important for both the initial MVP release and for subsequent change request updates following production go-live. However, when prioritizing features for an MVP release, the over-riding focus is on delivering the core MVP functionality that solves the primary problem for users. The initial release will have lots of features, but they ultimately need to accrue to the MVP definition of value, which is typically linked to a business process. On the other hand, when evaluating CRs post-MVP, the focus shifts to enhancing and expanding the existing functionality based on a myriad of user feedback and market needs. Instead of being measured against your MVP definition, you will likely have many more individual CRs that all demand to be addressed – this will increase the complexity of making prioritization decisions.

Once you’ve established clear priorities for items in the backlog, this should be reflected into your work management process or system. We have discussed Kanban as a suggested method for work management. It is particularly well suited for incremental delivery as it provides clear visibility to the scope and progress against the backlog at any point in time, which facilitates collaboration and discussion about priorities. It also uses a continuous ‘push’ delivery model where teams can review backlog items and release value as soon as they are ready; this is especially well suited during ‘Everyday Delivery’ as it gives you tremendous flexibility in releasing variable amounts of capability as soon as you are ready.

Once you have groomed and prioritized the backlog, you can start to build and test enhancements. This will be similar to the activities performed during the Prototype-to-MVP stage and will largely be focused around designing, building and testing using the no-code development tools. However, as noted above, it’s likely that post-MVP feature development may include many more individual CRs – often smaller in scope, as they may reflect smaller feature requests and ‘polishing’ you have identified based upon your user and system feedback channels.

Here are the main steps involved in this stage:

• Identify enhancements – these are drawn from your prioritized backlog.

• Design enhancements - Refer to Stage 5 of the Toolkit guidance (Prototype to MVP).

• Build enhancements - Refer to Stage 5 of the Toolkit guidance (Prototype to MVP).

• Test enhancements – This covers the use of manual or automated testing. Refer to Stage 5 of the Toolkit guidance (Prototype to MVP).

• Refine enhancements - Based on the results of testing and validation.

• Deploy enhancements – Refer to Stage 8 of the Toolkit guidance (First Release).

• Monitor enhancements - This is an ongoing cycle of ensuring proper functioning of new features or enhancements, performance metrics, etc. This feedback will come to you through user and system feedback techniques described in Stage 6 (Feedback Collection).

It is a temptation to address each of these CRs independently, without looking at the larger picture. This may result in, over time, the design of the application becoming more ‘cluttered’ and can lead to lower user satisfaction and reduced productivity. It also may result in inconsistencies of experience. So it is recommended to implement some general design checklists like the following example.

Design Consideration	Description	Criteria for Evaluation
User Interface	The design of the user interface (UI) for the feature	Is the UI easy to use and intuitive? Is it visually appealing? Does it follow best practices for UI design?
Accessibility (if applicable)	The ability of the feature to be used by people with disabilities	Does the feature comply with accessibility guidelines? Can it be used by people with visual, hearing, or mobility impairments?
Performance	The speed and responsiveness of the feature	Does the feature perform quickly and smoothly? Does it use system resources efficiently?
Scalability	The ability of the feature to handle large volumes of data or traffic	Will the feature be able to handle large volumes of users or data? Is it designed to scale as usage grows?
Security	The protection of data and user privacy	Does the feature have appropriate security measures in place? Does it comply with data protection regulations?
Integration	The ability of the feature to work with other systems or tools	Can the feature integrate with other systems or tools the user may be using? Are there any compatibility issues?
Maintenance	The ease of maintaining and updating the feature	Will it be easy to maintain and update the feature as needed?
User Experience	The overall experience of using the feature	Does the feature provide a positive user experience? Is it enjoyable to use and meets the needs of the user?

Checklists like this are not all-inclusive, but will help the no-code team ensure that as they process the detailed stream of small incremental enhancements, they are keeping in mind considerations that are critical to longer-term user value, adoption and driving lower-cost of operations for the solution.

In Stage 7, we discussed that Governance checks are essential to avoiding legal and financial penalties, reputational damage, project delays or failure, etc. In the initial release you should have taken a collaborative approach to this effort, involving multiple stakeholders with the necessary expertise to conduct comprehensive governance checks for your no-code app MVP release. However, it’s just as important to continue to perform these checks post the Go-live release. The frequency and depth of the checks may vary depending upon your industry or governance requirements; you should consult with the CoE or with internal Governance stakeholders to agree around the right cadence of performing checks that is necessary for your no-code app.

However, as you need to continue to deliver more frequent updates as part of an Everyday Delivery mindset, the effort of the Governance check becomes a key factor in how often and frequently you can release. While it’s possible to test (and retest), Governance checks in a completely manual fashion, this can result in having to plan for significant manual testing and validation steps with each release. In an Everyday Delivery model, the desired speed of delivery may result in teams sometimes cutting corners on Governance that will ultimately expose the project to risks.

It therefore is highly recommended to consider use of automated Governance testing as part of your strategy. Keep in mind though, that the automation itself will also need to be reviewed and updated.

• Evolving requirements may lead to new or updated governance checks. Proactively review with your compliance team or CoE if new reviews are needed.

• Periodically review Roles-based access policies to ensure they are appropriately enforced and controlled for new features.

• New backend integrations or user types may require additional security reviews.

• New types of data collected (e.g. sensitive company data), may trigger new requirements on data governance.

If the organization has implemented a Center of Excellence (CoE), the CoE will often play a key role in facilitating the use of governance automation, collaborating with internal and external governance stakeholders, and the updates needed to policy/controls that are addressed by the automation.