Showing posts with label #Rentals. Show all posts
Showing posts with label #Rentals. Show all posts

Thursday, 31 July 2025

WHAT IS A JAD SESSION

30 July 2025


Let's look at a definition and early history of JAD and SSADM, take a look at the roles of the participants and design a template agenda.

A JAD session - short for Joint Application Development session -  is a structured meeting that brings together business users, developers, and analysts to collaboratively define system requirements or design solutions. It’s particularly useful during the early stages of a software project.

JAD was a response to slow and error-prone traditional methods of gathering system requirements going way back to the 1970s, a methodology developed at IBM by Chuck Morris and Tony Crawford.

SSADM - Structured Systems Analysis and Design Method - dates back to the early 1980s. It was developed under contract to the UK government’s Central Computer and Telecommunications Agency (CCTA) as a standardised method for analysing and designing information systems.

By the mid 1990s, SSADM was on the way out due to the rise of RAD (Rapid Application Development), Agile, and object-oriented methods.

Object-Oriented Methods (OOM) are a way of designing and building software systems based on the concept of “objects”. These are self-contained units that combine data and behaviour, an approach mirrors the way we understand real-world entities like a car, a user, or a booking.. each has its own characteristics and actions.

An object has

- Attributes (data/state) — e.g., a User has a name, email, password.

- Methods (behaviour) — e.g., a User can log in, edit a profile, make a booking.

- Objects belong to classes, which are like blueprints for creating multiple similar objects. User gives hosts and guests.


🔍 What Happens in a JAD Session?

  • Facilitated workshop, often lasting several hours to a few days
  • Focused on rapid consensus-building
  • Participants work through use cases, data flows, interfaces, or UI mockups
  • Typically led by a facilitator, with a scribe, users, and technical experts
Business users who know the domain
Analysts who map the requirements
Developers who understand system capabilities

🧩 Typical Roles in a JAD Session

Role Responsibility
Facilitator Guides the discussion, ensures all voices are heard
Scribe Takes detailed notes, records decisions and diagrams
Business Users Share domain knowledge, describe real-world processes
Developers Ask clarifying questions, assess technical feasibility
Analysts Translate discussion into models, user stories, or specs

✅ Advantages

  • Cuts down on back-and-forth emails
  • Produces a shared understanding of goals
  • Captures accurate, detailed requirements
  • Increases buy-in from all stakeholders

📌 Use Case for Rentals

If rhe team were all co-located or online for a few hours, it would be possible to run a JAD session to:

  • Finalise feature priorities for the MVP
  • Walk through the booking flow from a user's perspective
  • Agree on UI elements based on tester feedback
  • Tackle tricky areas like deposit handling or ICal sync

Here's a JAD session agenda or template for the team.


📌 JAD session agenda

- 🎯 Purpose: Finalise MVP features, align design + functionality Participants: • 

Facilitator: Project lead analyst • Developers: [Insert Names] • Testers / Users: [Insert Names]

Session Agenda:

1. Welcome + Goals Overview (10 min)

2. Review of Core User Flows (20 min)

3. Feature Prioritisation Discussion (20 min)

4. UI/UX Walkthrough with Feedback (20 min)

5. Issue Resolution and Open Questions (15 min)

6. Wrap-up + Action Plan (5 min)

[End]

Friday, 18 July 2025

A HISTORY OF THE AGILE METHODOLOGY

18 July 2025


1. Overview

The Agile methodology is a set of principles for software development that prioritise flexibility, customer collaboration, and quick delivery over rigid planning and documentation.

2. Origins of Agile

Before Agile, software was typically developed using the Waterfall model – a linear, sequential process.

Problems arose: requirements changed mid-project, documentation-heavy processes slowed delivery, and customers often got what they asked for but not what they needed.

3. Precursors to Agile
Several lightweight, iterative methods emerged to address Waterfall's weaknesses:

Rapid Application Development (RAD)

Scrum (developed in the 1990s)

Extreme Programming (XP)

Feature-Driven Development (FDD)
These shared similar values: shorter cycles, user involvement, and adaptability.

4. The Agile Manifesto (2001)

Seventeen software developers met in Utah and created the Agile Manifesto, which formalised Agile principles.

It valued:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a fixed plan

5. Post-Manifesto Evolution

Agile grew into various frameworks like Scrum, Kanban, Lean, and SAFe.

Widely adopted across industries, not just in software.

6. Conclusion
Agile emerged as a reaction to rigid methodologies. Its success lies in delivering usable software faster while adapting to change and maintaining close collaboration with users.

Glossary
Waterfall Model – a step-by-step, linear approach to software development.
Iterative – a cyclical process where feedback and adjustments happen continuously.
Agile Manifesto – a declaration of the core values and principles guiding Agile.
Scrum/XP/FDD – specific Agile frameworks or methodologies.

Source:

[End]

AGILE AND SSADM COMPARED, WHAT IS A USER STORY

17 July 2025


Agile User Stories and SSADM



1. Summary: What is a User Story?

A user story is a short, simple description of a feature or requirement written from the perspective of the person who desires the functionality - typically a user or customer. In Agile development, user stories replace traditional system requirements to promote flexibility, collaboration, and fast iteration.

A user story typically follows the format:
“As a [type of user], I want [an action] so that [a benefit/a value].”

This ensures the feature is grounded in user value. User stories are intentionally brief and act as placeholders for further conversation and refinement. They are prioritised in a product backlog, broken down into epics or tasks, and selected for development during sprint planning.

A well-written user story is INVEST:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable

The 'Three Cs' of user stories are:
- Card: The written description (usually on a card or in a tracking system)
- Conversation: Dialogue among stakeholders to clarify and refine
- Confirmation: Acceptance criteria that confirm completion

This method supports iterative development, continuous feedback, and stakeholder engagement.

2. Glossary of Agile User Story Methodology

·        User Story: A brief, simple description of a feature from the user's perspective.

·        Agile: A methodology emphasizing iterative development, collaboration, and flexibility.

·        Product Backlog: A prioritized list of all desired work or features.

·        Epic: A large user story that can be broken down into smaller ones.

·        Task: A technical work unit derived from a user story.

·        Sprint: A fixed time period for completing selected user stories.

·        Sprint Planning: A meeting to choose which user stories to implement during a sprint.

·        INVEST: Checklist for good user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

·        Three Cs: Card (description), Conversation (discussion), Confirmation (acceptance criteria).

·        Acceptance Criteria: Conditions that must be met for a story to be complete.

·        Customer-Centric: Focus on delivering value to the user, not internal technical needs.

3. Comparison of Agile User Stories vs. SSADM

SSADM (Structured Systems Analysis and Design Methodology) is a waterfall methodology focused on thorough planning, rigorous documentation, and structured stages: feasibility, requirements analysis, logical data modeling, etc. It is best for stable and regulated environments.

Agile uses evolving user stories instead of static requirements. It values working software, frequent feedback, and adaptation. Documentation is minimal and collaboration is central.

Agile’s user stories fit a 'Three Layered' approach to requirements:
1. Epics (high-level goals)
2. Stories (concrete features)
3. Tasks (developer-level implementation units)

In contrast, SSADM follows:
1. Business Requirements
2. Functional Specification
3. Technical Specification

Where SSADM assumes requirements are knowable upfront, Agile embraces change and iterative clarification.

4. Glossary Mapping: Agile vs. SSADM

Agile Term

SSADM Equivalent

Comment / Mapping Logic

User Story

Process Specification

Describes functionality; refined into DFD and ELH in SSADM

Epic

Business Area Definition

High-level domain requirements

Task

Elementary Process / Module

Breakdown of a process step in DFD

Product Backlog

Requirements Catalogue

Centralised list of required system behaviours

Sprint

Phase in Project Plan

Time-boxed execution within structured lifecycle

Acceptance Criteria

Test Specification

Formal validation in SSADM

Three Cs

Structured Interview + Requirement Statement

Story lifecycle mirrors early SSADM stages

INVEST

Requirement Quality Guidelines

SSADM lacks explicit acronym but uses best practice

Card

Requirement Entry

Initial placeholder; becomes documented formally in SSADM

Conversation

Stakeholder Workshops

Corresponds to structured interviews and JAD sessions

Confirmation

Verification via Test Plan

Formalised in SSADM Test and Evaluation phase

Backlog Grooming

Requirements Review Meeting

SSADM equivalent is periodic review cycles

Logical Model

LDM (Logical Data Model)

Agile infers data; SSADM models explicitly

Flow of Interaction

DFD (Data Flow Diagram)

DFDs model data movement—analogous to interaction flow

State or Scenarios

ELH (Entity Life History)

Entity behaviour over time; maps loosely to user scenarios


What is a JAD session?

[End]