Process & Methodologies

A sprint is a fixed-length iteration delivering a working increment; planning at its start picks and sizes backlog work. A retrospective at the end lets the team reflect on the process and agree improvements. Grooming continuously clarifies and orders the backlog.

Agile is iterative and incremental: deliver working increments in short cycles, welcome changing requirements, and favour collaboration and feedback over a fixed plan. Waterfall is sequential — requirements, design, build, test, release — each phase finished before the next.

Decomposition is breaking a large backlog item into smaller, independently deliverable pieces. It makes work estimable, lets pieces be built and tested in parallel, surfaces hidden complexity early, and keeps increments small enough to finish within a sprint. A good split yields pieces that each deliver value or move the feature forward, rather than arbitrary fragments that only make sense together.

The SDLC flows through requirements, design, development, testing, deployment, and maintenance — sequential phases in Waterfall, repeated each iteration in Agile. The analyst leads requirements and design, then supports build, testing, and release.

Kanban is a pull-based flow method: visualize work on a board, limit work in progress (WIP), and improve flow. A WIP limit caps how many items sit in a column at once, so the team finishes work before pulling more, exposing bottlenecks. There are no fixed sprints.

They span Waterfall (sequential phases, full spec up front), iterative and spiral models, and Agile frameworks like Scrum and Kanban (short cycles, evolving scope). Waterfall has the analyst spec everything early; Agile has him groom a living backlog continuously.

Refinement (grooming) is the ongoing session where the team clarifies, splits, and estimates upcoming items for a future sprint. The analyst brings clear descriptions, acceptance criteria, and dependencies. A story is 'ready' when it meets the Definition of Ready — understood, testable, and small enough.

Scrum's five events: the Sprint is the time-boxed container; Planning sets the goal and picks the work; the Daily syncs progress and surfaces blockers; the Review inspects the increment with stakeholders for feedback; and the Retrospective agrees process improvements.

Scrum has three roles — Product Owner (owns and prioritizes the backlog), Scrum Master (facilitates the process, removes impediments), and Developers (build the increment) — and three artifacts: the Product Backlog, the Sprint Backlog, and the Increment.

Velocity is the story points a team completes per sprint, averaged over several — a capacity gauge for forecasting, not a productivity score. A burndown chart plots remaining work against time, showing whether the sprint is on track. Both are trend signals, not targets.

The analyst owns the 'what' — needs, requirements, and constraints; the architect and developers own the 'how' — technology, structure, and code. The analyst supplies requirements and clarifies intent but does not dictate technical choices, while the architect designs and developers build.

The analyst gives QA testable requirements and clear acceptance criteria, so testers can derive cases and know what 'correct' means. He clarifies expected behaviour and edge cases, and treats bugs that expose ambiguous or missing requirements as feedback to fix the spec.

The Product Owner owns backlog priority, ranking items by value, cost, risk, and dependencies — often via MoSCoW, RICE, or weighted scoring. The analyst supports it, supplying effort-and-impact estimates, surfacing dependencies, and clarifying scope so the PO ranks on facts.

A task can be split by business-process stages, by positive versus negative scenarios, by process conditions, by operation types, by platform, by data types, by roles and access rights, or by user scenarios. Pick the axis that yields independent, valuable, testable pieces.

Scrum runs in fixed sprints with set roles and ceremonies and a scope committed per sprint; Kanban is continuous flow with WIP limits, no sprints, and change allowed any time. Pick Scrum for planned iterative product work; pick Kanban for steady, shifting work like support or ops.

After release the analyst keeps living artifacts current — the requirements spec, user and API docs, process and data models, and the knowledge base. Support and QA read them to triage issues, developers to grasp existing behaviour, new hires to onboard, and the business to plan changes.

The Product Owner owns the vision and backlog — deciding what to build and in what order to maximize business value. The systems analyst works out how a requirement is realized, specifying and modelling it precisely. The PO answers 'what and why'; the analyst answers 'how'.

The analyst leads elicitation, requirements, and specification, and co-owns design. Later, in development, testing, and release, he is a consultant — clarifying requirements and checking the build matches the spec — while developers, QA, and DevOps own those stages.

First check whether automation helps — sometimes fixing the business process beats automating a broken one. Do a coarse feasibility pass: rough decomposition, large-block design, an early risk read. Surface constraints in three groups — business, technical, infrastructure.

Scrum fits small cross-functional teams on an evolving product with uncertain scope, where fast feedback helps. It fits poorly with contract-fixed scope and deadlines, heavy regulation, or rare releases — there a plan-driven Waterfall approach fits better.

Separate 'less delivered' from 'measured differently' — check estimation drift and re-baselined points. Examine requirements quality (churn and vague stories cause rework), dependencies, blockers, and scope creep. Requirements signals like reopened stories I fix; delivery signals like outages or attrition I escalate.

SMART is a checklist for well-formed goals: Specific (clearly defined), Measurable (you can tell when it is met), Achievable (realistic given resources), Relevant (aligned with the broader objective), and Time-bound (has a deadline). It turns a fuzzy wish into a trackable target.