Team Workflow and Project Management

Introduction and Context

Web application development is often described as a technical activity, but successful delivery also depends on coordinated human work. A team may possess strong programming skills and still fail because requirements are unclear, code changes conflict, tasks are poorly prioritised, risks are ignored, or stakeholders receive misleading progress information. Project management provides the structures through which technical work becomes planned, visible, reviewable and accountable.

In a full-stack project, workflow connects product discovery, interface design, frontend development, backend development, database work, testing, deployment and maintenance. The purpose is not to impose unnecessary bureaucracy. Rather, a good workflow reduces avoidable rework while preserving the team's ability to respond to learning and change.

This chapter presents a practical management approach for diploma-level web development teams. It combines Git branching, issue tracking, Agile and Kanban practices, estimation, sprint planning, risk management, change control, communication, documentation and accountability.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain why workflow and project management are essential to web application delivery.
2. Select and apply an appropriate Git branching strategy.
3. Create useful issues, acceptance criteria and a prioritised backlog.
4. Compare Scrum-style sprints with Kanban flow and select a suitable approach.
5. Estimate work, plan a sprint and monitor progress responsibly.
6. Maintain a risk register and apply practical risk responses.
7. Manage scope changes through a transparent change-control process.
8. Communicate with stakeholders and maintain adequate project documentation.
9. Demonstrate team accountability through reviews, evidence and retrospectives.

1. The Project as a Socio-Technical System

A web project is a socio-technical system: people, processes, tools and technology interact to produce an outcome. Technical quality and project quality are related but not identical. A system can be well coded but delivered too late, or delivered on time but be insecure and difficult to maintain.

A project normally has several constraints:

• Scope: what the product will and will not provide.
• Time: deadlines, milestones and release windows.
• Resources: people, skills, equipment, services and budget.
• Quality: functional, usability, performance, security and maintainability expectations.
• Risk: uncertain events that may affect objectives.

These constraints interact. Adding a feature may increase development time and testing effort. Reducing testing may appear to protect a deadline but can increase operational risk. Project management therefore involves making trade-offs explicitly rather than allowing them to occur accidentally.

A useful distinction is between an output and an outcome. A completed login page is an output. Enabling authorised users to access the system securely and conveniently is an outcome. Teams should plan and evaluate work against outcomes, not merely count completed tasks.

2. Roles, Responsibilities and Accountability

Small student or professional teams may combine roles, but responsibilities should still be visible. Typical roles include:

One person can hold more than one role, but the team should not assume that responsibility exists merely because a title exists. A responsibility matrix can clarify ownership. The RACI model is often useful: Responsible people perform the work; the Accountable person owns the result; Consulted people provide input; and Informed people receive updates.

Accountability is evidence-based. Examples of evidence include a linked issue, a pull request, review comments, test results, deployment records and an acceptance decision. Accountability should not mean blame. It means that the team can determine what was agreed, what happened, what evidence exists and what action is required next.

3. Git as a Collaborative Workflow

Git is a distributed version-control system. It records snapshots of a project, allows parallel work and supports review before changes enter a shared branch. Git does not replace communication: a technically valid merge can still introduce an unwanted product change.

3.1 Repository conventions

Before coding begins, the team should establish:

• a meaningful repository name;
• a README containing setup and usage instructions;
• an agreed default branch;
• a contribution guide;
• coding, testing and formatting conventions;
• an issue and pull-request template;
• rules for secrets, environment variables and generated files;
• a policy for reviewing and merging changes.

Secrets such as passwords, API keys and private certificates must not be committed. A local environment file may be used during development, while a safe example file documents required variable names without exposing values.

3.2 Branching strategies

A branch represents an independent line of development. Common strategies include:

For a diploma project, short-lived feature branches are generally a practical default. A typical sequence is:

1. Update the local default branch.
2. Create a branch linked to an issue, such as feature/142-password-reset.
3. Make small, coherent commits.
4. Run formatting, tests and security checks locally.
5. Push the branch and open a pull request.
6. Obtain review and address comments.
7. Merge only when the acceptance conditions and quality checks are satisfied.
8. Delete the branch if it is no longer needed.

Commit messages should explain intent, for example, “Validate password-reset token expiry” rather than “changes”. A commit should ideally represent one logical change. Large mixed commits make review, testing and rollback more difficult.

3.3 Pull requests and code review

A pull request is a discussion and verification point, not merely a merge button. It should identify the issue, describe the change, state how it was tested and identify known limitations. Reviewers should examine correctness, security, maintainability, tests, accessibility and consistency with the product requirement.

Review comments should be specific and respectful. “This input accepts unchecked HTML; can we validate or safely encode it?” is more useful than “bad code”. The author remains responsible for improving the change, while the reviewer remains responsible for raising legitimate concerns.

A team should define branch-protection rules appropriate to its scale. A minimum policy may require a successful build, passing tests and one review before merging. The main branch should remain in a deployable state whenever practicable.

4. Requirements, Issues and the Product Backlog

An issue is a manageable record of a request, defect, task, risk or decision. An issue should be small enough to understand and track, but meaningful enough to produce evidence of progress.

A useful feature issue contains:

• a concise title;
• user or business context;
• a description of the desired behaviour;
• acceptance criteria;
• dependencies and assumptions;
• design or API references;
• priority and estimate;
• links to related issues.

A user-story form can help express value: “As a registered customer, I want to reset my password by email so that I can regain access without contacting support.” It is not a complete specification. Acceptance criteria are needed to make the expected behaviour testable, such as:

• a valid email receives a reset message;
• an unknown email does not reveal whether an account exists;
• the token expires after the defined period;
• a used token cannot be reused;
• the new password meets the stated policy.

Issues should not be confused with implementation steps. “Build controller, create route and update table” describes technical tasks. “Customer can securely reset a forgotten password” describes a user-visible capability. A feature may be decomposed into technical tasks, but the parent issue should preserve the user outcome.

Definition of Ready and Definition of Done

A Definition of Ready is a team agreement about when work is sufficiently understood to enter active development. It may require a clear goal, acceptance criteria, identified dependencies and an available design.

A Definition of Done is a shared quality threshold. It may require implemented behaviour, peer review, automated tests, updated documentation, accessibility checks, security checks and successful deployment to a test environment. “Code written” is not the same as “done”.

5. Agile and Kanban Workflows

Agile is a family of values and practices that emphasises early delivery, collaboration, feedback and adaptation. It does not mean “no planning”. Agile planning occurs at several horizons: product vision, release or milestone, iteration and daily work.

Scrum-style sprint workflow

A sprint is a fixed timebox during which a team pursues a goal and produces a usable increment. Typical events are:

• Sprint planning: select a realistic goal and work.
• Daily coordination: inspect progress and impediments briefly.
• Review: demonstrate the increment and collect stakeholder feedback.
• Retrospective: improve the team's process.

A sprint should have a goal, not merely a pile of unrelated tickets. Mid-sprint changes should be limited unless they are necessary to protect the product or respond to an emergency.

Kanban flow

Kanban visualises work on a board, for example: Backlog, Ready, In Progress, Review, Testing and Done. Work-in-progress limits restrict how many items may occupy a column. The aim is to expose bottlenecks and finish work before starting more work.

Kanban is particularly useful when priorities arrive continuously, support work interrupts planned development, or the team cannot make reliable fixed-sprint commitments. Scrum and Kanban are not mutually exclusive: a team may use a Kanban board within a regular review cycle.

The central difference is emphasis. Sprint planning focuses on a timeboxed commitment and goal; Kanban focuses on continuous flow, explicit policies and limiting work in progress. Neither approach guarantees success. Poor requirements, weak testing and excessive multitasking can undermine either method.

6. Estimation and Sprint Planning

Estimation is a forecast, not a promise. It supports prioritisation and capacity decisions while recognising uncertainty.

Relative estimation

Teams often use story points to compare relative size. A story-point estimate may reflect complexity, uncertainty, effort and dependencies. It is not a universal unit of time and should not be used to compare individual productivity across teams.

A common scale is 1, 2, 3, 5, 8 and 13. Large values indicate that an item may need decomposition. The team can use planning poker: members independently select estimates, explain assumptions and discuss differences before reaching a shared estimate.

Capacity-based planning

Before selecting sprint work, the team estimates available capacity. A simple planning model is:

Here, person-days available are working days multiplied by the number of people, and the focus factor is a value between 0 and 1 representing time lost to meetings, support, study, leave and other work. The model assumes that people are reasonably interchangeable and that the period is short. It is a planning aid, not a productivity law.

For example, four people have five working days each, but the team expects a focus factor of 0.7:

The team should not select work estimated at exactly 14 person-days if major uncertainty exists. A buffer is prudent, and dependencies should be considered separately.

Velocity and forecasting

If a team uses story points, velocity can be calculated for a completed iteration as the sum of accepted story points. A multi-sprint average may be used for forecasting:

V_i is the accepted velocity of iteration i, and n is the number of iterations. This is meaningful only when the team, estimation method and Definition of Done are reasonably stable. Velocity should not be used as a target or a basis for ranking teams.

Practical planning sequence

1. Confirm the product or sprint goal.
2. Review the highest-value ready items.
3. Check dependencies, capacity and risks.
4. Break oversized items into vertical slices that produce user value.
5. Select work that fits capacity with a sensible buffer.
6. Define the sprint outcome and any explicit exclusions.
7. Record assumptions and planning risks.

7. Monitoring Progress and Quality

A board is useful only when it reflects reality. Items should move when their state changes, not when a report is due. A daily coordination conversation should focus on progress toward the goal, next actions and impediments rather than lengthy status speeches.

Useful indicators include:

• Lead time: time from request or selection to completion.
• Cycle time: time from active work to completion.
• Throughput: number of completed items in a period.
• Work in progress: items currently active.
• Defect trends: defects opened, resolved and reopened.
• Build and test status: evidence that the product remains technically healthy.

No single metric represents productivity or value. A team can increase throughput by delivering trivial tasks while neglecting important outcomes. Metrics should support learning, not surveillance or competition.

A simple cumulative-flow diagram can reveal growing queues, but interpretation requires context. A widening “Testing” band may indicate insufficient testers, unstable builds or oversized work items. The appropriate response is to investigate the system rather than pressure individuals to work faster.

8. Risk Management

A risk is an uncertain event that may affect objectives. An issue is a problem that has already occurred. A risk register makes uncertainty visible.

A practical risk register contains:

For a quantitative screening model, risk exposure may be represented as:

P is the estimated probability of occurrence, expressed as a value from 0 to 1, and I is the estimated impact measured in an agreed scale such as cost, days or points. This multiplication is only meaningful when the impact scale is defined consistently; it should not create false precision. Many educational and small-team registers appropriately use qualitative ratings instead.

Example risks include an unavailable third-party API, loss of a key team member, unclear data-protection requirements, database migration failure, insecure authentication, and stakeholder unavailability. A response might be to create a mock API, document setup steps, test migrations on a copy, obtain early privacy advice or schedule regular stakeholder reviews.

9. Change Control and Scope Management

Change is normal in web development because users learn from prototypes, regulations evolve and technical constraints become visible. Uncontrolled change, however, causes scope creep and undermines commitments.

A lightweight change-control process is:

1. Record the change request in an issue.
2. Clarify the reason, expected benefit and urgency.
3. Analyse effects on scope, time, quality, security, architecture and dependencies.
4. Identify options, including postponement or removal of another feature.
5. Obtain an authorised decision from the product owner, client or agreed governance group.
6. Update the backlog, plan, requirements and risk register.
7. Communicate the decision and rationale.
8. Verify the result after implementation.

A useful principle is “change one constraint consciously”. If a new feature must enter a fixed deadline, the team may reduce another feature, add approved resources or accept a revised quality or release boundary. It should not silently absorb the change and hope that quality will survive.

Emergency changes, such as a security fix, may follow an expedited path, but they still require a recorded reason, review and post-change evaluation.

10. Communication and Documentation

Communication should be purposeful, timely and accessible. A communication plan can specify the audience, information, channel, frequency and owner.

Important decisions should be written in an accessible decision log. A good record states the context, options considered, decision, consequences, owner and date. Documentation should be maintained as part of delivery, not postponed indefinitely.

Useful project documents include the README, product vision, backlog, acceptance criteria, architecture overview, API documentation, database migration notes, test strategy, deployment runbook, risk register, decision log, meeting decisions and retrospective actions. Documentation must be proportionate: a small application does not require an enterprise bureaucracy, but a future maintainer must be able to install, understand, test and operate the system.

11. Applied Case: Campus Event Booking Application

The following is an illustrative case, not a report of a real organisation.

Background

A four-person diploma team is asked to develop a web application through which students can discover campus events and reserve places. The project has six teaching weeks. The client expects a working demonstration at the end of week six.

Problem

The initial request contains twenty-three desired features, including event search, accounts, reservations, email reminders, payment, attendance scanning, administration and analytics. The team has limited experience with payment integration and the client representative can attend only one meeting each week.

Analysis

The team identifies three major risks: payment integration may exceed available time; unclear privacy expectations may affect student data; and the client may interpret “working demonstration” as requiring all twenty-three features. The team conducts a prioritisation workshop and defines a minimum viable outcome: students can view events, create an account, reserve a limited number of places and receive a confirmation message; staff can create and cancel events.

The team selects short-lived feature branches with pull requests. It uses a Kanban board with limits of three items in development and two in review. A weekly review provides stakeholder feedback, while brief daily coordination meetings expose blockers.

Approach and solution

The backlog is rewritten as vertical slices with acceptance criteria. Payment and attendance scanning are recorded as later possibilities rather than hidden commitments. A privacy review identifies the minimum personal data required and prohibits exposing whether an email address is registered during password recovery.

Capacity is estimated as four people × five days per week × 0.65 focus factor, or 13 person-days per week. The team reserves time for testing, documentation and academic obligations. Rather than using all available capacity, it selects a smaller first slice and builds a basic deployment pipeline.

A risk register assigns the payment issue to the technical lead, privacy questions to the product owner and deployment reliability to a developer. The team creates a mock email service for development and tests database migrations before each release. Every pull request links to an issue and must pass automated checks.

During week four, the client requests analytics. The team records a change request and explains that implementing it immediately would threaten reservation reliability and testing. The client accepts postponement in exchange for a simple administrative count on the event page.

Outcome

At the demonstration, students can browse events, reserve places and receive confirmation. Staff can manage events. The system has documented setup instructions, a test deployment and a known limitations list. Payment, scanning and advanced analytics remain outside the demonstrated release but are represented in the backlog with initial risks.

Learning points

1. Scope became manageable when the team defined an outcome rather than attempting every requested feature.
2. Branching and pull requests made technical work visible and reviewable.
3. A risk register encouraged early mitigation instead of late crisis response.
4. Change control enabled the client to make an informed trade-off.
5. Documentation and deployment evidence were part of “done”, not post-project decoration.
6. The team measured progress through usable increments and feedback rather than lines of code.

12. Challenges, Ethics and Contemporary Practice

Common challenges

Teams frequently encounter unclear ownership, oversized tasks, excessive parallel work, review bottlenecks, unreliable estimates and meetings that produce no decisions. Remedies include smaller work items, explicit policies, work-in-progress limits, review rotation, protected focus time and retrospective experiments.

Remote and hybrid teams require particular care. Shared written updates, timezone-aware scheduling, recorded decisions and asynchronous review reduce dependence on informal conversations. However, asynchronous communication should not become an excuse to avoid difficult collaborative decisions.

Ethical and governance responsibilities

Project management affects people as well as schedules. Teams must protect user privacy, avoid collecting unnecessary data, consider accessibility, use licensed software and represent progress honestly. Stakeholder pressure does not justify concealing defects or bypassing security review. Personal performance metrics should be handled carefully because counting commits or tickets can reward harmful behaviour and discourage collaboration.

Data protection obligations depend on jurisdiction and context, but good practice generally includes purpose limitation, data minimisation, access control, retention decisions and secure handling of credentials. Accessibility should be included in acceptance criteria rather than treated as a final cosmetic check.

Technology and AI

Issue trackers, continuous integration, automated tests, dependency scanners and deployment pipelines can improve visibility and repeatability. AI-assisted coding may help generate drafts, tests or documentation, but generated output requires human review. Teams must check licensing, privacy, security vulnerabilities, factual accuracy and whether confidential project material has been disclosed to an external service. AI does not transfer accountability away from the developer or project owner.

Best-Practice Checklist

Before and during delivery, a team should be able to answer yes to most of the following:

• Is the product outcome and current scope explicit?
• Does each active item have an owner, acceptance criteria and a linked branch or evidence?
• Is the main branch protected by review and automated checks?
• Are work-in-progress limits or equivalent focus rules being respected?
• Are estimates treated as forecasts rather than promises?
• Are risks assigned, reviewed and connected to mitigation actions?
• Are changes recorded and approved at the appropriate level?
• Can a new developer install, test and understand the project?
• Are stakeholder decisions and unresolved assumptions documented?
• Does the Definition of Done include security, accessibility and testing where relevant?
• Does the team inspect its process and implement retrospective improvements?

Chapter Summary

Team workflow and project management transform individual technical contributions into coordinated product delivery. Git provides version history and collaboration mechanisms, while branching conventions, pull requests and review rules protect shared code. Issue tracking converts goals into visible, testable work; acceptance criteria and Definitions of Ready and Done establish shared meaning.

Agile sprint practices support timeboxed goals and regular feedback, whereas Kanban emphasises continuous flow and limits on work in progress. Estimation and capacity planning support informed decisions but do not create certainty or justify ranking individuals by velocity. Risk registers expose uncertainty, and change control makes trade-offs explicit. Communication plans, decision logs and proportionate documentation preserve shared understanding.

The illustrative event-booking case demonstrates that successful delivery depends on prioritisation, technical discipline, stakeholder negotiation, risk mitigation and evidence of quality. Ethical practice requires honest reporting, privacy protection, accessibility, secure development and responsible use of automation and AI. The central principle is that a project is managed well when its people can understand the goal, see the current reality, make informed decisions and deliver a usable, maintainable outcome.

Key Terms

Agile: A family of approaches emphasising collaboration, feedback, incremental delivery and adaptation.

Acceptance criteria: Conditions that must be satisfied for a requirement to be accepted.

Backlog: An ordered collection of requested, planned or potential work.

Branch: An independent line of development in a version-control repository.

Capacity: The amount of work a team can reasonably undertake during a period.

Change control: The process for assessing, approving and recording changes.

Cycle time: The time from starting active work to completing it.

Definition of Done: Shared criteria determining whether work is complete and acceptable.

Estimation: A forecast of the relative size, effort or uncertainty of work.

Issue: A tracked record of a feature, defect, task, risk or decision.

Kanban: A flow-based approach using visualisation, explicit policies and work-in-progress limits.

Lead time: The time from a request or selection until completion.

Pull request: A proposed code change submitted for review and integration.

Risk register: A maintained record of uncertainties, effects, owners and responses.

Scrum: An Agile framework using roles, events, artefacts and fixed-length sprints.

Sprint: A fixed timebox for producing a usable increment toward a goal.

Stakeholder: A person or group affected by, interested in or able to influence a project.

Throughput: The number of work items completed in a specified period.

Velocity: The amount of accepted estimated work completed by a team in an iteration.

Work in progress: Work that has started but is not yet complete.

Review Questions

Short Answer Questions

1. Why should a project distinguish between an output and an outcome?
2. What information should be included in a useful feature issue?
3. Explain the purpose of a Definition of Done.
4. State two differences between sprint-based planning and Kanban flow.
5. Why must secrets not be committed to a Git repository?

Long Answer Questions

1. Describe a short-lived feature-branch workflow from issue creation through pull-request merge. Explain how it supports quality.
2. Explain how a team can estimate capacity for a sprint and why the result should not be treated as a guarantee.
3. Describe the structure and purpose of a project risk register, including suitable risk responses.
4. Explain a lightweight change-control process and discuss the consequences of uncontrolled scope change.
5. Discuss how communication, documentation and accountability contribute to successful full-stack project delivery.

Analytical / Application Questions

1. A team of five has four working days available in a sprint and expects a focus factor of 0.75. Calculate its simple available capacity in person-days and explain why the team might plan below that figure.
2. A Kanban board shows that many items are waiting in Testing while Development remains full. Analyse two likely causes and propose practical interventions.
3. A stakeholder requests a new payment feature two weeks before release. Using the case-study principles, explain what information should be gathered, how the request should be evaluated and what decision options should be presented.

Multiple Choice Questions with Answers

Question 1

Which practice most directly protects the main Git branch from unreviewed changes?

A. Allowing every developer to commit directly

B. Requiring pull-request review and successful automated checks

C. Deleting all feature branches before testing

D. Using longer commit messages without review

Correct Answer: B. Requiring pull-request review and successful automated checks

Question 2

What is the primary purpose of acceptance criteria?

A. To identify every person attending a meeting

B. To define conditions for deciding whether a requirement is satisfied

C. To calculate the team's salary budget

D. To replace all software testing

Correct Answer: B. To define conditions for deciding whether a requirement is satisfied

Question 3

A team has four people, five working days and a focus factor of 0.7. What is its simple available capacity?

A. 7 person-days

B. 10 person-days

C. 14 person-days

D. 20 person-days

Correct Answer: C. 14 person-days

Question 4

Which statement best describes story points?

A. A universal unit of developer productivity

B. A relative indication of size, effort and uncertainty

C. The exact number of hours required for a task

D. A measure that should be used to rank individuals

Correct Answer: B. A relative indication of size, effort and uncertainty

Question 5

What is the central emphasis of Kanban?

A. Continuous flow and limiting work in progress

B. Annual planning with no reprioritisation

C. Merging every branch without review

D. Completing the largest tasks first

Correct Answer: A. Continuous flow and limiting work in progress

Question 6

Which item belongs in a risk register?

A. Only completed source-code files

B. A risk owner, response and trigger

C. The personal opinions of every user

D. A list of programming languages only

Correct Answer: B. A risk owner, response and trigger

Question 7

What should normally happen when a stakeholder requests a significant new feature during a fixed release?

A. Implement it secretly without changing the plan

B. Ignore it permanently

C. Record and analyse its effects before an authorised decision

D. Remove all testing to create time

Correct Answer: C. Record and analyse its effects before an authorised decision

Question 8

Which statement about velocity is most accurate?

A. It should be used to compare individual developers

B. It is a forecast based on accepted estimated work and team context

C. It is always equal to available person-days

D. It must increase every iteration

Correct Answer: B. It is a forecast based on accepted estimated work and team context

Question 9

Why is a Definition of Done important?

A. It creates a shared quality threshold for completed work

B. It prevents stakeholders from giving feedback

C. It eliminates the need for a backlog

D. It guarantees that estimates are correct

Correct Answer: A. It creates a shared quality threshold for completed work

Question 10

Which is an ethical project-management practice?

A. Hiding known security defects until after release

B. Collecting unnecessary personal data for convenience

C. Reporting progress honestly and including relevant security and accessibility checks

D. Using commit counts as the sole measure of contribution

Correct Answer: C. Reporting progress honestly and including relevant security and accessibility checks