Blog Archives

How to Organise User Stories across Sprints

31/10/2023

Let us learn this with the following examples

Online Shopping Website:
- Sprint 1:
  - As a customer, I want to search for products by keyword, so that I can find what I'm looking for quickly.
  - As a customer, I want to create an account, so that I can save my preferences and order history.
- Sprint 2:
  - As a customer, I want to add products to my shopping cart, so that I can purchase them later.
  - As a customer, I want to view my shopping cart, so that I can see what I've added.
- Sprint 3:
  - As a customer, I want to checkout and make a payment, so that I can complete my purchase.
  - As a customer, I want to receive a confirmation email, so that I can track my order.

Travel Booking App:
- Sprint 1:
  - As a user, I want to search for flights, so that I can find one that meets my requirements.
  - As a user, I want to filter my search results by price, duration, and airline, so that I can make an informed decision.
- Sprint 2:
  - As a user, I want to book a flight, so that I can secure my travel plans.
  - As a user, I want to view my itinerary, so that I can see all my booked flights.
- Sprint 3:
  - As a user, I want to cancel a booked flight, so that I can make changes to my travel plans.
  - As a user, I want to receive a confirmation email, so that I can keep track of my booking.

Project Management Tool:
- Sprint 1:
  - As a user, I want to create a new project, so that I can start organizing my work.
  - As a user, I want to add team members to my project, so that we can collaborate.
- Sprint 2:
  - As a user, I want to create tasks within my project, so that I can break down my work.
  - As a user, I want to assign tasks to team members, so that we can work together.
- Sprint 3:
  - As a user, I want to track the progress of tasks, so that I can see how the project is progressing.
  - As a user, I want to generate reports on project status, so that I can share updates with stakeholders.

This is how we can split user stories across multiple sprints, allowing the team to deliver value incrementally and iteratively.

Attributes of an User Story

31/10/2023

"User stories are the currency of meaningful conversation in agile development, translating customer needs into actionable work for the team."

A user story is a concise, informal description of a software feature or functionality from the perspective of an end user. User stories are a common way to capture and communicate requirements in agile development methodologies, particularly in Scrum. User stories typically consist of several key attributes, which help teams understand and prioritize the work to be done. These attributes include:

Title or Header: A brief, descriptive title that summarizes the essence of the user story. It should be simple and easy to understand.

User Role: The user or persona for whom the feature is being developed. This helps the team understand who will benefit from the feature.

User Story Statement: A short, narrative description of the feature, often written in the following format: "As a [user role], I want [an action] so that [benefit/value]." For example, "As a customer, I want to be able to reset my password so that I can regain access to my account."

Acceptance Criteria: Detailed, specific conditions or criteria that must be met for the user story to be considered complete. These criteria define the scope and functionality of the story and serve as a basis for testing and validation

Priority: The relative importance of the user story in the product backlog. It can be assigned a priority value or ranked based on the needs of the project or product.

Estimate: An estimate of the effort required to implement the user story. This could be in terms of story points, ideal days, or any other unit of measurement the team uses for estimating work.

Definition of Done (DoD): The agreed-upon set of criteria that must be satisfied for the user story to be considered "done" and ready for release. It ensures that the feature is complete and meets the team's quality standards.

Dependencies: Any external factors, user stories, or tasks that the team needs to consider or address while working on this user story.

Notes and Comments: Additional information or context that might be relevant to the user story, such as technical considerations or clarifications.

Attachments: Any relevant documents, mock-ups, or diagrams that can help in understanding and implementing the user story.

User stories are intended to be brief and focused on the user's perspective, allowing for flexibility and adaptability in agile development. The goal is to provide just enough information to initiate a conversation between team members, including developers, testers, and product owners, to refine and implement the feature effectively.

How to schedule your Software Project

31/10/2023

"Failing to plan is planning to fail." - Alan Lakein

When scheduling a software project, it's essential to establish a structured approach to prioritizing requirements. This process can be organized into four key categories: Efficiency, Curtsy, Exigency, and Emergency, often represented by the acronym "ECEE."

Efficiency: Prioritizing for efficiency means considering the natural order in which project modules should be developed. This involves sequencing requirements based on their interdependencies, ensuring that foundational components are built before more complex features. By adhering to this order, the development process becomes smoother, as modules are constructed in a logical and progressive manner. Example: You have to build a software system for your client which has functionalities for

Employee Database
Employee Attendance
Leave
Payroll.

The efficient or natural order to develop this system could be 1-2-3-4

Curtsy: The 'Curtsy' approach focuses on client satisfaction by giving priority to requirements that are most important to the client. These could be features that directly address the client's needs, preferences, or competitive advantages. By putting the client's wishes at the forefront, the project is more likely to result in a product that meets or exceeds their expectations. Continuing with our earlier example project let us say this project takes 4 months to complete and let us hypothetically assume each of the 4 modules will be delivered in 4 iterations or 4 delivery cycles or 4 sprints. However the client has to start his business and has the preference to immediately mark the attendance to start with. In this case the project can be taken up with capturing / importing say employee id (unique) , employee name and moving ahead with the attendance module.

So here the order to develop the system will be 2-3-4-1

"Time management is not about doing more; it's about doing what matters." - Unknown

Requirements Prioritisation Techniques - Must haves for a Business Analyst toolkit

31/10/2023

Requirements Prioritisation Matrix

"The key is not to prioritize what's on your schedule but to schedule your priorities." – Stephen R. Covey

Requirements prioritization is a fundamental aspect of project management and product development. It involves the strategic ranking of requirements based on their importance, value, and impact on the overall project goals. By prioritizing requirements, teams can focus their efforts on the most critical features, ensuring that resources are allocated effectively and that high-value functionalities are delivered early. This process helps in managing scope and adapting to changing project dynamics, aligning stakeholder expectations, and delivering the most valuable components first, thereby increasing the project's chances of success. Effective requirements prioritization is a key element in delivering products that meet customer needs and achieve project objectives while staying within constraints and timelines.

"You can do anything, but not everything." – David Allen

Requirement Prioritisation Techniques in Agile Development

5 Common Insurance Processes

29/10/2023

Insurance Domain or Insurance competency has become a steady revenue earner for IT companies. Demand for Business Analysts, Subject Matter Experts and Product Owners is on a significant uptrend. Here we cover 5 common Non-Life Insurance Processes.

Non-life insurance, is also known as property and casualty insurance. This covers a wide range of insurance types that provide protection against risks other than life and health. Here are five common non-life insurance processes:

Underwriting Process: Underwriting is the process of assessing the risk associated with insuring a potential policyholder and determining the terms and conditions of the insurance policy. Non-life insurance companies use various data sources and risk assessment models to evaluate the likelihood of a claim occurring. This process helps insurers set appropriate premiums and coverage limits.
Claims Processing: Claims processing involves managing and evaluating insurance claims made by policyholders who have experienced a loss or damage covered by their insurance policy. This process includes verifying the claim, assessing the extent of the damage, and determining the compensation amount based on the terms of the policy.
Policy Issuance and Management: This process involves the creation, issuance, and ongoing management of insurance policies. It includes capturing customer information, setting up policy terms, generating policy documents, and ensuring accurate record-keeping throughout the policy's lifecycle.
Premium Collection and Accounting: Premium collection is the process of collecting insurance premiums from policyholders. Non-life insurance companies manage billing cycles, payment processing, and account reconciliation. This process is crucial for maintaining the financial health of the insurance company.
Risk Assessment and Loss Prevention: Non-life insurance companies engage in risk assessment and loss prevention activities to reduce the likelihood of claims. This involves offering risk management advice to policyholders to help them mitigate potential risks, implementing safety guidelines, and promoting practices that reduce the occurrence of covered incidents.

These processes collectively support the functioning of non-life insurance companies, ensuring that policyholders are protected against a wide range of risks and that the insurer's operations are efficient and profitable.

If you have what it takes and you wish to take up a role of a Business Analyst or Subject Matter expert you can whatsapp us at https://wa.me/919810055734

Difference between Business Analyst and a Financial Analyst

28/10/2023

Business Analyst Vs Financial Analyst

Analyst is a pretty generic word, An Analyst has to analyze a problem , situation, question, requirement in detail and come up with insights, solutions etc

IT Business Analyst and Financial Analyst are two distinct roles within the business world, each with its own set of responsibilities and areas of focus. Here are the key differences between these two roles:

Focus of Analysis:
- IT Business Analyst: An IT Business Analyst primarily focuses on the information technology (IT) aspects of a business. They work to bridge the gap between business needs and IT solutions. Their main responsibilities include gathering and analyzing business requirements, documenting processes, and designing IT systems or software solutions to meet those requirements. They often work on projects related to software development, system implementation, or process improvement.
- Financial Analyst: A Financial Analyst, on the other hand, primarily focuses on financial data and activities within a business. They analyze financial statements, market trends, investment opportunities, and economic factors to provide insights and recommendations related to financial decision-making. Financial Analysts work with financial data to assess the company's financial health, make investment recommendations, and help with budgeting and forecasting.
Types of Analysis:
- IT Business Analyst: IT Business Analysts perform process analysis, requirements analysis, and system analysis. They identify inefficiencies in business processes and recommend technology solutions to streamline operations. They also work with stakeholders to understand their needs, create functional specifications, and support the development and implementation of IT solutions.
- Financial Analyst: Financial Analysts conduct financial analysis, investment analysis, and risk analysis. They evaluate financial data to provide insights into investment opportunities, assess the company's financial performance, and help in decision-making related to investments, budgeting, and financial planning.
Skill Sets:
- IT Business Analyst: IT Business Analysts require a combination of technical knowledge and business acumen. They need skills in requirements gathering, data analysis, system design, and communication to bridge the gap between business stakeholders and IT teams.
- Financial Analyst: Financial Analysts need strong analytical and financial modeling skills. They should be well-versed in financial tools, accounting principles, and market analysis. Additionally, communication and presentation skills are crucial for conveying financial information effectively.
Typical Industries:
- IT Business Analyst: IT Business Analysts are commonly found in industries that heavily rely on IT systems and software, such as technology companies, finance, healthcare, and retail. They play a crucial role in software development projects, system upgrades, and process optimization.
- Financial Analyst: Financial Analysts work in a wide range of industries, including banking, investment firms, insurance, corporate finance, and government. They are essential in helping businesses make informed financial decisions and managing their resources.

In summary, while both IT Business Analysts and Financial Analysts perform analysis, their areas of focus, types of analysis, skill sets, and typical industries differ significantly. IT Business Analysts primarily work on IT-related projects, while Financial Analysts focus on financial data and decisions within a business.

What is SAFe Agile , What it has to do with Scrum

28/10/2023

SAFe Certification for a bullet proof career

SAFe is the new name in the Scrum Game, more and more professionals are enquiring about SAFE

SAFe, or the Scaled Agile Framework, is an agile framework designed to help large organizations adopt and implement agile and lean practices at scale. SAFe provides a structured approach to agile transformation and is intended to guide enterprises in achieving business agility while delivering value to customers more efficiently and effectively. It was developed by Scaled Agile, Inc.
Key components and concepts of the SAFe framework include:

Principles: SAFe is built on a set of principles that align with the values and principles of the Agile Manifesto. These principles guide organizations in their journey toward agility, emphasizing concepts such as customer-centricity, decentralized decision-making, and promoting a Lean-Agile mindset.
Roles: SAFe defines specific roles within organizations, including the Release Train Engineer (RTE), Product Owner, Scrum Master, and various leadership roles. These roles play a critical part in the agile transformation and the execution of SAFe.

What is a Baselined Requirement

28/10/2023

Whether the given requirement has been 'Baselined' or not is an oft heard word on software projects

A "baselined requirement" refers to a requirement that has undergone a formal approval process and has been established as a stable and agreed-upon reference point for a project or system. When a requirement is baselined, it means that it has been documented, reviewed, and approved by relevant stakeholders, and any subsequent changes to that requirement will need to go through a formal change management process.
Here are some key points to understand about baselined requirements:

Documentation: Baselined requirements are typically documented in a requirement specification document. This document serves as a reference for all project stakeholders and contains detailed information about the requirement, such as its description, priority, acceptance criteria, and any dependencies.
Approval: Before a requirement is baselined, it goes through a review and approval process. This process involves stakeholders, such as business analysts, project managers, and subject matter experts, who assess the requirement for completeness, correctness, and feasibility.
Stability: Once a requirement is baselined, it is considered stable. This means that it should not be subject to frequent changes without a valid reason. Changes to baselined requirements typically require formal approval and impact analysis to assess how they may affect the project.
Reference Point: Baselined requirements serve as a reference point for project planning, development, and testing. They help ensure that everyone involved in the project is working based on a common set of agreed-upon specifications.
Change Management: If a change to a baselined requirement is necessary due to changing project needs or new insights, a formal change request process is typically initiated. This process assesses the impact of the proposed change on the project, and if approved, it results in an updated version of the requirement.
Traceability: Baselined requirements are often used to establish traceability, which means connecting each requirement to the corresponding design, implementation, and testing activities. This ensures that all project components align with the established requirements.

Overall, baselined requirements are a fundamental part of project management and system development. They provide clarity and stability to project teams and help mitigate risks associated with uncontrolled changes to project specifications.A "baselined requirement" refers to a requirement that has undergone a formal approval process and has been established as a stable and agreed-upon reference point for a project or system. When a requirement is baselined, it means that it has been documented, reviewed, and approved by relevant stakeholders, and any subsequent changes to that requirement will need to go through a formal change management process.

Linkage between Business Vision, Business Goal, Functional Requirement, User Story and Test Case for a Software System

28/10/2023

Buisness Vision, Business Goals, Business Requirements

Business requirement, functional requirement, user story, test case flow from Business Vision and Business Goals

Business Vision: To revolutionize the healthcare industry by providing a comprehensive Electronic Health Records (EHR) system that enhances patient care, streamlines medical processes, and improves data accessibility.

Business Goal: Improve patient care and streamline medical operations by implementing a user-friendly EHR system within the next 18 months.

Business Requirement: The EHR system must support the electronic storage and retrieval of patient records, enable healthcare professionals to access patient data quickly, and ensure data security and compliance with relevant regulations.

Functional Requirements: The system shall allow authorized healthcare professionals to create, update, and retrieve patient records. Patient records shall include personal information, medical history, medications, and test results. The system shall provide role-based access control to ensure data security and compliance. It shall enable the attachment and viewing of medical images (e.g., X-rays, MRIs). The EHR system shall have a search functionality for quick access to patient records. All patient data shall be encrypted and stored securely. The system shall generate automated alerts for medication reminders and follow-up appointments.
User Story: As a healthcare professional, I want to access patient records securely and quickly so that I can provide efficient and high-quality patient care.
This user story represents a real-world scenario from the perspective of a user (healthcare professional) and encapsulates the need for accessing patient records securely and efficiently. It ties back to the business requirement of ensuring data security and quick access to patient records within the EHR system, contributing to the broader business goal of improving patient care and medical operations.
Certainly, here's an example of a business vision, business goal, business requirement, functional requirement, test case, and user story for a software system:

Test Case: Test Case Title: Verify Access Control
Description: This test case aims to verify that the access control mechanisms in the EHR system are functioning correctly.
Preconditions:

A user account with Nurse role exists.
A user account with Doctor role exists.
A patient record is created and associated with both Nurse and Doctor.

Test Steps:

Log in with the Nurse account.
Attempt to access a patient record associated with the Doctor role.
Verify that access is denied.

Expected Result: Access to the patient record associated with the Doctor role should be denied for the Nurse account.

How to Organise User Stories across Sprints

Attributes of an User Story

"User stories are the currency of meaningful conversation in agile development, translating customer needs into actionable work for the team."

How to schedule your Software Project

"Failing to plan is planning to fail." - Alan Lakein

"Time management is not about doing more; it's about doing what matters." - Unknown

Requirements Prioritisation Techniques - Must haves for a Business Analyst toolkit

"The key is not to prioritize what's on your schedule but to schedule your priorities." – Stephen R. Covey

"You can do anything, but not everything." – David Allen

Requirement Prioritisation Techniques in Agile Development

5 Common Insurance Processes

Insurance Domain or Insurance competency has become a steady revenue earner for IT companies. Demand for Business Analysts, Subject Matter Experts and Product Owners is on a significant uptrend. Here we cover 5 common Non-Life Insurance Processes.

Difference between Business Analyst and a Financial Analyst

Analyst is a pretty generic word, An Analyst has to analyze a problem , situation, question, requirement in detail and come up with insights, solutions etc

What is SAFe Agile , What it has to do with Scrum

SAFe is the new name in the Scrum Game, more and more professionals are enquiring about SAFE

What is a Baselined Requirement

Whether the given requirement has been 'Baselined' or not is an oft heard word on software projects

Linkage between Business Vision, Business Goal, Functional Requirement, User Story and Test Case for a Software System

Business requirement, functional requirement, user story, test case flow from Business Vision and Business Goals

Archives

Services

Company

Support

​"User stories are the currency of meaningful conversation in agile development, translating customer needs into actionable work for the team."

"Failing to plan is planning to fail." - Alan Lakein​

"Time management is not about doing more; it's about doing what matters." - Unknown

"The key is not to prioritize what's on your schedule but to schedule your priorities." – Stephen R. Covey​

"You can do anything, but not everything." – David Allen​

Requirement Prioritisation Techniques in Agile Development

Insurance Domain or Insurance competency has become a steady revenue earner for IT companies. Demand for Business Analysts, Subject Matter Experts and Product Owners is on a significant uptrend. Here we cover 5 common Non-Life Insurance Processes.

Analyst is a pretty generic word, An Analyst has to analyze a problem , situation, question, requirement in detail and come up with insights, solutions etc

SAFe is the new name in the Scrum Game, more and more professionals are enquiring about SAFE

Whether the given requirement has been 'Baselined' or not is an oft heard word on software projects

Business requirement, functional requirement, user story, test case flow from Business Vision and Business Goals

Archives

Services

Company

Support

"User stories are the currency of meaningful conversation in agile development, translating customer needs into actionable work for the team."

"Failing to plan is planning to fail." - Alan Lakein

"The key is not to prioritize what's on your schedule but to schedule your priorities." – Stephen R. Covey

"You can do anything, but not everything." – David Allen