Bona Iqiniso Functional Vision Board
Introduction
Epic
Refers to a large and high-level body of work that is too complex or extensive to be completed in a single development cycle or iteration. Epics are used as a way to organize and manage projects.
The highest level of the Bona Iqiniso Vision Board (Application Board) is the collection of the Bona Iqiniso Epics. Bona Iqiniso Epics are large, high-level pieces of functionality or requirements that are used to represent a significant business value in the Bona Iqiniso development process. Bona Iqiniso Epics are too large to be delivered in a single sprint and are therefore broken down into smaller, more manageable stories that can be completed in individual sprints.
A Bona Iqiniso Epic provides a high-level view of the work that needs to be done and the value that it will deliver to the Bona Iqiniso business. It helps to define the overall scope of the Bona Iqiniso project and provides a way to organize the development team’s work into meaningful chunks that align with the goals and objectives of the project. It also covers major chunks of logically grouped functionality.
Bona Iqiniso Epics are created and managed in the Bona Iqiniso Vision Board (Agile backlog). Bona Iqiniso is an experienced-based methodology and tool, and therefore, its vision board is constantly reviewed and refined, with new stories and epics being added.
Feature
Refers to a distinct and self-contained functionality or capability that is added to a software application or product. Features are the building blocks that enhance the overall functionality of the software and provide specific benefits to the end-users.
Features refer to the characteristics, capabilities, or attributes of the Bona Iqiniso product and services that define its functionality, usefulness, and overall value. In the context of the Bona Iqiniso software development, features refer to the specific functions, tools, and interfaces that are included in the Bona Iqiniso software application to support its intended use.
It is good to know that Epics are, in fact, a collection of functionality that is grouped in a logical way. For example the epic Bona Iqiniso Configuration contains all the functionality that is available to configure the Bona Iqiniso Application.
This functionality is called ‘features’.
Examples of features that may be included:
- User interface: A graphical user interface (GUI) that allows users to interact with the application in a visual and intuitive way.
- Data storage: The ability to store and manage data, such as customer information, transaction records, and product data.
- Data analysis: Tools and algorithms for analyzing data, such as reporting, analytics, and data visualization.
- Workflow management: The ability to manage processes, such as order fulfillment, invoicing, and project management.
- Integration: The ability to integrate the application with other software and hardware systems, such as databases, web services, and enterprise resource planning (ERP) systems.
- Security: Measures to protect the data and functionality of the application, such as encryption, access control, and data backup and recovery.
The specific features included in the Bona Iqiniso Application will depend on its intended use, the target market, and the requirements of the organization that is building it and the organizations that are using it. The goal is to provide a comprehensive set of features, logically grouped in epics, that meet the needs of the target users and provide value to the organizations.
Features can be delivered in one go or in several increments. The first delivery of a feature is always the MVF or minimal viable feature.
An MVF is designed to have only the minimum set of actions that are necessary to test the feature idea and validate the concept.
Each feature is detailed by a number of User Stories
Story
Refers to a user story, which is a concise, informal description of a feature or functionality from the perspective of an end-user or a customer. User stories are a fundamental component of Agile methodologies, particularly in Scrum, where they serve as the building blocks of the product backlog.
User stories are used for capturing the requirements and specifications for a feature. A user story is a short, simple description of a feature’s requirements from the perspective of a user, and is written in plain language.
The goal of user stories is to define the functionality that the feature should provide. The way user stories are written follows the acronym SMARTER.
SMARTER is used to define the characteristics of well-written requirements. SMARTER stands for:
- Specific: A specific requirement clearly and precisely defines what the user story should do, what it should be capable of, or what it should look like. It also means that enough information is available to start coding the user story.
- Measurable: A measurable user story can be quantified (story points) to enable better planning and reporting. This quantification can be used to determine the user story is ‘simple’ enough.
- Achievable: An achievable user story is realistic and feasible within the given constraints and limitations of the project. It has a defined deadline for completion or a specific timeframe within which it must be satisfied. Typically, a user story can be made in one sprint (2 to 4 weeks period).
- Relevant: A relevant requirement is directly aligned with the goals and objectives of the feature and is of value to the stakeholders.
- Testable: A user story must be testable to verify it is built in the correct way.
- Economical: An economical requirement is cost-effective and efficient and does not introduce unnecessary expenses or waste.
- Risk-Mitigated: A risk-mitigated requirement takes into account potential risks and hazards and includes measures to mitigate or minimize their impact.
The SMARTER framework helps ensure that requirements are well-defined and aligned with the project goals and provides a means for evaluating the quality and effectiveness of user stories.
User stories are written in a specific format, following the structure “As a [user], I want [goal or desired outcome], so that [benefit or value]”.
For example, a user story might be: “As a Thaste developer, I must be able to define all labels of a component so that I can easily build the component in angular, without worrying about labels or translations.”
User stories are created by a product owner or stakeholders and are used as the basis for planning, designing, and developing the Bona Iqiniso software. They are an important tool as they provide a clear and concise way of defining the requirements for a feature and ensuring that everyone has a shared understanding of what the software should do.
User stories are also used to prioritize the development work, as the most important stories can be prioritized and implemented first, and the less important stories can be deferred or removed if necessary. By breaking the software requirements into smaller, more manageable chunks, user stories help to make the development process
Recent Comments