Skip to navigation | Skip to main content | Skip to footer

COMP33711 Agile Software Engineering syllabus 2019-2020

COMP33711 materials

COMP33711 Agile Software Engineering

Level 3
Credits: 10
Enrolled students: 99

Course leader: Suzanne Embury

Additional staff: view all staff


  • Pre-Requisite (Compulsory): COMP23311
  • Pre-Requisite (Compulsory): COMP23412
  • Pre-Requisite (Compulsory): COMP23420

Additional requirements

  • Students who are not from the School of Computer Science must have permission from both Computer Science and their home School to enrol.

Assessment methods

  • 100% Written exam
Sem 1 w1-5,7 ROOM SETUP/SETDOWN IT407 Fri 14:30 - 15:00 -
Sem 1 w1-5,7 Lecture IT407 Fri 15:00 - 17:00 -
Sem 1 w1-5,7 ROOM SETUP/SETDOWN IT407 Fri 17:00 - 17:30 -
Sem 1 w8-11 Lecture 1.8 Fri 15:00 - 17:00 -
Sem 1 w8-11 Lab Toot 0 Fri 15:00 - 17:00 -
Sem 1 w12 Lecture 2.25B Fri 15:00 - 17:00 -
Sem 1 w12 Lecture IT407 Fri 15:00 - 17:00 -
Themes to which this unit belongs
  • Agile Methods


In 2001, a group of influential and experienced software developers met in the mountains of Utah to discuss was going wrong in software development and how things could be done differently. Together, they produced the Agile Manifesto, a concise summary of the key values they agreed should underpin successful software development. In essence, these values state that: we should value the people involved and their interactions more than the processes and tools used; we should focus on the delivery of working code over the production of comprehensive documentation; we should strive for effective collaboration with the customer rather than wrangling over contract details; and we should aim to respond sensibly to change rather than sticking rigidly to our original plan, which may no longer be appropriate.

Much conventional software engineering is based around a key idea from manufacturing: namely, the notion that the quality of a product depends on the quality of the process that creates it. According to this way of thinking, if we aren't developing good software products then we need to have a better process with which to develop them. Unfortunately, as the proponents of agile methods point out, rather than better processes, we often ended up only with bigger processes, requiring an ever increasing set of deliverables to be produced: feasibility studies, statements of project scope, project plans, requirements specifications, risk assessment plans, interview reports, contracts, architecture designs, detailed designs, test strategy documents, test plans, change requests, etc., etc. But in the end, say the agile proponents, the only deliverable that matters is the delivered code. Why are we diverting so much effort and energy to these other deliverables, at the expense of the one that really matters?

The Agile Manifesto, and the work on lightweight software development approaches that preceded it, led to the design of several new software development methods, all coming under the title of "agile methodologies". These approaches seek to focus the efforts of the project team on the activities that lead directly to the delivery of genuinely useful software for the customer. They give a key role to the customer in achieving this value, and suggest radical ways in which customers and developers should interact. They reduce (or abolish) the role of middle managers, and put decision making power back in the hands of the development team, to reduce delays in information flow and to increase the quality of communication between the customer and developers. They use cheap and cheerful approaches to heavyweight tasks such as requirements gathering, emphasising the need to be flexible, and to embrace change as an inevitable necessity rather than something to be feared and resisted.

Initially heavily criticised, many agile practices are now becoming the accepted way of working in the software industry. The number of organisations claiming to be wholly or partly agile is fast increasing, and an awareness of agile approaches (their limitations as well as their strengths) is invaluable for anyone contemplating a career as a software engineer.


The aim of this course unit is to introduce you to the basic values and principles behind agile software engineering, and to give you an understanding of how the key agile practices work together to deliver real value to customers in a predictable and controllable way. We'll look at some of the problems with the conventional "plan-based" approach to software development, and examine how agile methods attempt to do better.

Rather than being lectured at, you'll take part in industry-standard coaching games, plus team-based exercises, group discussions and hands-on demonstrations that let you experience the agile approach at work and make up your own mind about the strengths and limitations of the ideas being presented.


  • Week 1: The Agile Lego Game - an Introduction to Agile Software Engineering
  • Week 2: The Trouble with Big Up-Front Requirements Gathering
  • Week 3: How Do We Know What to Build?
  • Week 4: What Can We Promise to Deliver (and When)?
  • Week 5: How Do We Know What to Build Next?
  • Week 7: How Do We Know When We're Done?
  • Week 8: How Do We Build the Right Product?
  • Week 9: How Do We Know When We're (Done) Done? (sic)
  • Week 10: How Do We Build The Product Right?
  • Week 11: Software Design Without A Crystal Ball?
  • Week 12: Agile in a Nutshell

For a detailed description of each weeks' activities please see COMP33711's weekly lesson plan.

Teaching methods


One two-hour session per week

Feedback methods

During lectures, many team and whole group activities are undertaken, with feedback being given face-to-face during the activities and in the whole-group debrief sessions afterwards.

A series of self-tests are available for students to try after lectures, with detailed feedback being provided by the automatic marking system.

Feedback can be obtained on interim versions of coursework at any of the (optional) clinic sessions. Written comments will be provided on returned marked coursework, with pointers towards aspects of the work that the student did well and suggestions for areas where further study might be required.

Study hours

  • Assessment written exam (2 hours)
  • Lectures (22 hours)
  • Practical classes & workshops (22 hours)

Employability skills

  • Group/team working
  • Project management
  • Oral communication
  • Problem solving
  • Written communication

Learning outcomes

Programme outcomeUnit learning outcomesAssessment
A2 A7Students should be able to explain the problems with conventional, "plan-based" approaches to software engineering, specifically the "Big Up-Front" approaches to software requirements gathering and specification, software project planning and software design. (Comprehension Level)
  • Individual coursework
  • Examination
A2 A6 B3Students should be able to explain the motivation behind the four agile values and the twelve agile principles, and give examples of how they might apply in a given scenario to solve a perceived development problem. (Comprehension Level, Application Level)
  • Individual coursework
  • Examination
A2 B1 D9Students should be able to write user stories to capture user requirements and their associated business values, and to successively refine them until they describe a unit of functionality that can be implemented within a single (short) iteration. (Synthesis Level)
  • Examination
  • Individual coursework
A2 A4 B1 D3 D9Students should be able to create release and iteration plans given a collection of stories with relative business values and size estimates, based on an evaluation of their technical risk and the learning opportunities they present. (Synthesis Level, Evaluation Level)
  • Examination
  • Individual coursework
A2 B1 D9Students should be able to apply agile estimation techniques to software development tasks, and to use these estimates in release and iteration planning. (Application Level)
  • Individual coursework
  • Examination
A2 A4 A7 D3 D9 D10Students should be able to set up and use a task board to capture the status of a software project, to track changes as they occur and to support decision making in a self-organising team (Application Level)
  • Examination
  • Individual coursework
A2 B1 B2 C5 D3 D9 D10Students should be able to use specification-by-example techniqes to create a specification for a set of user stories in the form of executable acceptance tests. (Synthesis Level)
  • Individual coursework
  • Examination
A7 D3 D9 D10Students should be able to use automated acceptance, integration and unit tests to drive the design of a software system in an evolutionary/emergent manner, using the principles of Acceptance Test Driven Design (ATDD) and Unit Test Driven Design (TDD). (Synthesis Level, Analysis Level)
  • Examination
  • Individual coursework
A7 D3 D9 D10Students should be able to pair programme following the core guidelines for pairing, and to apply variants such as ping-pong pairing. (Application Level)
  • Individual coursework
  • Examination
A2 A4 B3 D3 D9Students should be able to use agile retrospective techniques to detect and diagnose problems in their team process, and to suggest steps that could be taken to improve the overall team performance. (Analysis Level, Synthesis Level)
  • Individual coursework
  • Examination
A6 C7Students should be able to explain how formal contracts/funding models for agile projects differ from contracts/funding models from more traditional projects.
  • Examination

Reading list

Art of agile developmentShore, James and Shane Warden9780596527679O'Reilly Media2007
Test driven: practical TDD and acceptance TDD for Java developersKoskela, Lasse9781932394856Manning2008
User stories applied: for agile software developmentCohn, Mike9780321205681Addison Wesley2004
Growing Object-Oriented software, guided by testsFreeman, Steve and Nat Pryce0321503627Addison Wesley2009
Agile estimating and planningCohn, Mike0131479415Prentice Hall2005
User story mapping: discover the whole story, build the right productPatton, Jeff and Peter Economy9781491904909O'Reilly2014
Integrating agile development in the real worldSchuh, Peter9781584503644Charles River Media2004
Test-driven development by exampleBeck, Kent9780321146533Addison Wesley Signature Series2002
Lean software development: an agile toolkitPoppendieck, Mary and Tom Poppendieck9780321150783Addison Wesley2003

Additional notes

Course unit materials

Links to course unit teaching materials can be found on the School of Computer Science website for current students.