Agile Software Development (CS-703 (C)) Unit 2 Notes

How unit 2 is examined

This unit covers how agile teams are formed, how an agile project moves from vision to release, and how it is monitored and improved. No past question has been asked on any topic, so every topic is short but complete.

Planning for Agile Teams: Scrum Teams

Not asked since 2022

Definition. A Scrum team is a small, self-organizing, cross-functional group of a Product Owner, a Scrum Master and Developers who together deliver a working product increment every sprint.

Key points.

The Product Owner owns the product backlog and decides what is built and in what order.
The Scrum Master is a servant-leader who coaches the team, enforces Scrum rules and removes impediments.
The Developers are cross-functional, holding all the skills (analysis, coding, testing) needed to finish a story without outside help.
A team is kept small, usually 5 to 9 people, so that communication stays easy and the team can commit to a sprint together.

XP Teams

Definition. An XP team is a co-located team of programmers, an on-site customer, a coach and a tracker who work together using practices such as pair programming and collective ownership.

Key points.

The on-site customer sits with the team, writes user stories and answers questions immediately.
Programmers work in pairs, so every line of code is reviewed as it is written.
Collective ownership means anyone may change any code, so no single person becomes a bottleneck.
The coach guides the team in applying XP practices, and the whole team shares an open workspace.

General Agile Teams

Definition. A general agile team is a self-organizing, cross-functional team that plans and manages its own work without a manager assigning tasks, whatever agile method it follows.

Key points.

Self-organizing means the team decides how to do the work and who does which task.
Cross-functional membership lets the team finish a complete feature on its own.
Team members are generalizing specialists: each has one deep skill but can help with other tasks.
Stable, dedicated members build trust and a steady velocity, so people should not be split across many projects.

Team Distribution

Definition. Team distribution describes how team members are spread across locations, from fully co-located to fully remote, and how agile practices are adapted to that spread.

Key points.

A co-located team gives the richest communication because face-to-face talk is the most effective channel.
In a distributed team, time zones, language and culture slow feedback and weaken trust.
Distributed teams compensate with video calls, shared boards, chat tools, continuous integration and a few overlapping working hours.
Each site should hold a whole cross-functional team, rather than splitting a team by skill across sites.

Agile Project Lifecycles: Typical Agile Project Lifecycles

Definition. An agile project lifecycle is an iterative and incremental sequence of phases in which the product is delivered in small working increments, with feedback after each one.

Key points.

A typical lifecycle has the phases Envision (vision), Speculate or Plan, Explore (iterations), Adapt (review) and Close.
Work is divided into short timeboxed iterations of one to four weeks, each producing a usable increment.
Requirements and plans are refined after every iteration, so change is welcome at any point.
Unlike the waterfall model, which finishes each phase before the next, agile repeats analysis, design, coding and testing inside every iteration.

Phase Activities

Definition. Phase activities are the specific tasks carried out in each phase of the agile lifecycle, from setting the vision to releasing and closing the project.

Key points.

In the initial phase the team defines the product vision, identifies stakeholders, forms the team and builds the first backlog.
In the planning phase the team estimates stories and prepares the release plan and the first iteration plan.
In each iteration the team plans, builds, tests and demonstrates working software, then holds a review and a retrospective.
In the release and closing phase the product is deployed, final documentation is done and lessons learned are recorded.

Product Vision

Definition. A product vision is a short statement that describes the purpose of the product, its target customers, the need it meets and what makes it different.

Key points.

The vision gives the whole team one shared goal and guides every later decision.
A common template reads: For (target customer) who (need), the (product name) is a (category) that (key benefit); unlike (competitor), our product (differentiator).
It is written by the Product Owner with stakeholders, and it is brief enough to be remembered.
Every backlog item is checked against the vision, and items that do not support it are dropped.

Release Planning: Creating the Product Backlog

Definition. Release planning decides which features will be delivered by a release date, and the product backlog is the ordered list of everything the product may need, from which the plan is built.

Key points.

The product backlog holds features, user stories, bugs and improvements, each with a description and a priority.
It is created from the vision by the Product Owner, the team and stakeholders, and it is never final.
Items at the top are small and detailed, while items at the bottom are large and vague.
Backlog grooming keeps it up to date by adding, splitting, removing and reordering items.

User Stories

Definition. A user story is a short description of a feature from the user's point of view, written as: As a (role), I want (goal), so that (benefit).

Key points.

A story has three parts, known as the three Cs: Card (the written text), Conversation (details discussed) and Confirmation (acceptance tests).
Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable.
Stories are estimated in story points, which measure relative size and not hours.
Example: As a student, I want to download past papers, so that I can revise for exams.

Prioritizing and Estimating

Definition. Prioritizing orders backlog items by value, and estimating gives each item a relative size, usually in story points using planning poker.

Key points.

MoSCoW sorts items into Must have, Should have, Could have and Will not have this time.
Other criteria for priority are business value, risk, cost and dependencies.
In planning poker each member privately picks a card from a Fibonacci-like scale (1, 2, 3, 5, 8, 13), all reveal together, and the team discusses differences until it agrees.
Relative estimates are faster and more reliable than absolute time estimates.

Creating the Release Plan

Definition. A release plan is a high-level roadmap that shows which stories will be delivered in which iterations, and the expected release date.

Key points.

It is built from the prioritized and estimated backlog, so high-value stories are scheduled first.
The team's velocity, the story points finished per iteration, gives the capacity of each iteration.
Number of iterations $=$ total story points $\div$ velocity; for example, 120 points at velocity 20 needs 6 iterations.
The plan is revised after every iteration as velocity and priorities change.

Monitoring and Adapting: Managing Risks and Issues

Definition. Monitoring and adapting means tracking progress, risks and issues continuously and changing the plan when the facts change; a risk is a possible problem, and an issue is a problem that has already happened.

Key points.

Progress is monitored with burndown charts, velocity, the task board and daily stand-ups.
Risks are recorded in a risk log with their probability and impact, then ranked by exposure.
Each risk is handled by avoiding it, mitigating it, transferring it or accepting it.
Issues are raised in the stand-up and the Scrum Master or project manager removes them quickly.

Retrospectives

Definition. A retrospective is a meeting held at the end of an iteration where the team reflects on how it worked and decides what to improve next.

Key points.

The team discusses three questions: what went well, what did not go well and what to change.
It is timeboxed, for example to 3 hours for a one-month sprint, and attended by the whole team.
The output is a small number of concrete action items, taken into the next iteration.
It supports continuous improvement and follows the agile principle of reflecting at regular intervals.

Last-minute revision

Scrum team: Product Owner, Scrum Master and Developers, 5 to 9 people, self-organizing and cross-functional.
XP team: on-site customer, pair programming, collective ownership, coach.
Co-located teams communicate best; distributed teams need video, shared boards and overlapping hours.
Agile lifecycle: Envision, Speculate, Explore, Adapt, Close, run in timeboxed iterations of 1 to 4 weeks.
Vision template: For (customer) who (need), the (product) is a (category) that (benefit); unlike (competitor)...
Product backlog is ordered, never final and groomed continuously.
User story: As a (role), I want (goal), so that (benefit); check with INVEST; three Cs: Card, Conversation, Confirmation.
MoSCoW: Must, Should, Could, Will not.
Planning poker uses the scale 1, 2, 3, 5, 8, 13.
Iterations needed $=$ total points $\div$ velocity.
Risk is a possible problem, issue is an actual problem; responses are avoid, mitigate, transfer, accept.
Retrospective questions: what went well, what did not, what to change.

Memory hooks

Scrum team roles: "PO decides what, SM clears the way, Devs build it."
INVEST spells out the good-story checklist.
MoSCoW: "Must Should Could Won't."
Risk is future, issue is now.
Retrospective: "Well, Wrong, Way forward."

Coverage checklist

Planning for Agile Teams: Scrum Teams: no past questions.
XP Teams: no past questions.
General Agile Teams: no past questions.
Team Distribution: no past questions.
Agile Project Lifecycles: Typical Agile Project Lifecycles: no past questions.
Phase Activities: no past questions.
Product Vision: no past questions.
Release Planning: Creating the Product Backlog: no past questions.
User Stories: no past questions.
Prioritizing and Estimating: no past questions.
Creating the Release Plan: no past questions.
Monitoring and Adapting: Managing Risks and Issues: no past questions.
Retrospectives: no past questions.

Account

Agile Software Development (CS-703 (C)) - Unit 2 Short Notes

How unit 2 is examined

Planning for Agile Teams: Scrum Teams

XP Teams

General Agile Teams

Team Distribution

Agile Project Lifecycles: Typical Agile Project Lifecycles

Phase Activities

Product Vision

Release Planning: Creating the Product Backlog

User Stories

Prioritizing and Estimating

Creating the Release Plan

Monitoring and Adapting: Managing Risks and Issues

Retrospectives

Last-minute revision

Memory hooks

Coverage checklist