Agile Methods - course notes

Introduction to Agile Methods
Introduction to Agile Methods (cc)-by-sa – Evan Leybourn Page 1 of 89
Student Guide
Introduction to Agile Methods by Evan Leybourn is licensed under a
Creative Commons Attribution-ShareAlike 3.0 Australia License
<http://creativecommons.org/licenses/by-sa/3.0/au/>
Evan Leybourn
evan@theagiledirector.com
Twitter: @eleybourn

OTHER WORKS BY
EVAN LEYBOURN
DIRECTING THE AGILE ORGANISATION –
BY EVAN LEYBOURN
http://theagiledirector.com/book
 Embrace change and steal a march on
your competitors
 Discover the exciting adaptive
approach to management
 Become the Agile champion for your
organisation
Business systems do not always end up the way that we first plan them. Requirements can
change to accommodate a new strategy, a new target or a new competitor. In these
circumstances, conventional business management methods often struggle and a different
approach is required.
Agile business management is a series of concepts and processes for the day-to-day
management of an organisation. As an Agile manager, you need to understand, embody
and encourage these concepts. By embracing and shaping change within your organisation
you can take advantage of new opportunities and outperform your competition.
Using a combination of first-hand research and in-depth case studies, Directing the Agile
Organisation offers a fresh approach to business management, applying Agile processes
pioneered In the IT and manufacturing industries.

TABLE OF CONTENTS
Other Works by Evan Leybourn................................................................................................2
Directing the Agile Organisation – by Evan Leybourn...........................................................2
Table of Contents.......................................................................................................................3
What Does Agile Mean?.............................................................................................................6
The Agile Manifesto ...............................................................................................................7
Agile Methods ........................................................................................................................8
Key Points...............................................................................................................................8
Understanding Waste ............................................................................................................9
Critical Success Factors........................................................................................................10
Common Misconceptions....................................................................................................11
Scrum Overview...................................................................................................................12
Kanban Overview.................................................................................................................14
Test Driven Development (TDD) Overview..........................................................................16
Extreme Programming (XP) Overview .................................................................................17
Feature Driven Design (FDD) Overview ...............................................................................17
Project Roles ............................................................................................................................19
Project Team ........................................................................................................................20
Interested and Committed ..................................................................................................20
Primary Roles.......................................................................................................................21
Project Initiation......................................................................................................................23
Specifications in Agile?.........................................................................................................24
Beginning the Process .........................................................................................................24
Outcomes.............................................................................................................................24
Backlog .................................................................................................................................25
Accuracy ...............................................................................................................................27

Estimating Effort ..................................................................................................................28
How?.....................................................................................................................................28
Estimating Time....................................................................................................................30
Cost / Time / Scope ..............................................................................................................31
Starting an Iteration ................................................................................................................33
Iteration Planning Meeting..................................................................................................35
During an Iteration..................................................................................................................39
Daily Lifecycle.......................................................................................................................40
Task Lifecycle........................................................................................................................41
Development Hints ..............................................................................................................43
Test Driven Development ....................................................................................................44
Continuous Integration........................................................................................................45
Scrum Meeting (aka Daily Stand-up) ...................................................................................48
Inspection.............................................................................................................................49
Burndown & Burnup Charts ................................................................................................50
Progress Problems...............................................................................................................51
Finishing an Iteration...............................................................................................................54
Iteration Review...................................................................................................................55
Kaizen and the Iteration Retrospective...............................................................................56
References ...............................................................................................................................57
Books & Links.......................................................................................................................58
Tools .....................................................................................................................................58
Supporting Material – Example Release and Test Management Plan....................................59
Schedule of Activities & Description of the Approval Process............................................60
Roles, Responsibilities and Resource Requirements ..........................................................63
Roll Back Strategy.................................................................................................................64
Testing Methodology ...........................................................................................................65
Mapping Between the Test Scripts and the Requirements ................................................67
Test Report Template...........................................................................................................68
Supporting Material – Example High-Level Business requirements......................................69
Glossary of Terms ................................................................................................................70
Introduction .........................................................................................................................70
Scope of Requirements Specification..................................................................................70
Functional Requirements.....................................................................................................71
Non-Functional Requirements ............................................................................................71

Requirements Imposed by Specific Legislation Strategies .................................................74
Constraints...........................................................................................................................74
Assumptions.........................................................................................................................75
Risks......................................................................................................................................75
Supporting Material – Example Technical Architecture .........................................................76
Conceptual System Design Section .....................................................................................77
Conceptual System Design Diagram ...................................................................................79
Detail System Design Checklist............................................................................................79
System Design Description ..................................................................................................83
Business Continuity .............................................................................................................83
Expected Issues....................................................................................................................83
Supporting Material – Example Design Page..........................................................................84
Supporting Material – Example Release Approval..................................................................86
Release Approval..................................................................................................................87
Compliance Outcome ..........................................................................................................87
Defect Testing Outcome ......................................................................................................87
Performance Testing Outcome............................................................................................88
Issues To Carry Over To The Next Release..........................................................................88
Sign Off.................................................................................................................................89

Notes:
WHAT DOES AGILE MEAN?
‘On two occasions I have been asked, “Pray, Mr Babbage, if you put into the
machine wrong figures, will the right answers come out?” [...] I am not able rightly
to apprehend the kind of confusion of ideas that could provoke such a question.’
Charles Babbage, 1864

Notes:
THE AGILE MANIFESTO
The “Agile Software Development Manifesto” was developed in February 2001, by
representatives from many of the fledgling “agile” processes such as Scrum, DSDM, and XP.
The manifesto is a set of 4 values and 12 principles that describe “What is meant by Agile".
THE AGILE VALUES
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
THE AGILE PRINCIPLES
1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter time-scale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximising the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organising
teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behaviour accordingly.

Notes:
AGILE METHODS
The term Agile actually refers to a concept, not a specific methodology. There are many,
and sometimes conflicting, methods that can be used under the Agile umbrella. These
include;
 Agile Unified Process,
 Behaviour Driven Development (BDD),
 Crystal Clear,
 Dynamic Systems Development Method (DSDM),
 Extreme Programming (XP)
 Feature Driven Development (FDD),
 Kanban
 Lean Development,
 Rapid Application Development (RAD),
 IBM - Rational Unified Process (RUP),
 Scrum,
 Test Driven Development (TDD),
KEY POINTS
All of the above methods have four key points in common.
1. Iterative design process
2. Continuous stakeholder engagement
3. Aims for quality and reliable software
4. Short development cycles (up to a month) allows to regular delivery of software
This shows that an Agile approach is appropriate in contexts where the outcomes are not
known (or can’t be known) in advance and where the delivery of the outcomes cannot be
fully controlled.

Notes:
The following figures1
are an excellent example of the differences between traditional (or
phased) software development vs. the Agile approach of iterative development.
FIGURE 1: THE TRADITIONAL APPROACH (PHASED DELIVERY OF KNOWN OUTPUTS)
FIGURE 2: THE AGILE APPROACH (ITERATIVE DELIVERY TO MEET CHANGING EXPECTATIONS )
UNDERSTANDING WASTE
The techniques and frameworks within Agile aim to increase development efficiency, by
eliminating all ‘wasteful’ processes. Drawing on the successful concepts from the Lean
manufacturing frameworks, we can define 3 major forms of waste.
1. Mura (Unevenness): Mura exists where there is a variation in workflow, leading to
unbalanced situations, most commonly where workflow steps are inconsistent,
unbalanced, or without standard procedures.
1
Images with thanks from Jeff Patton: http://www.agileproductdesign.com/

Notes:
2. Muri (Overburden): Muri exists where management expects unreasonable effort
from personnel, material or equipment, most commonly resulting from unrealistic
expectations and poor planning.
3. Muda (Waste): Muda is any step in the production workflow that does not add
direct value to the Customer. The original seven wastes, as defined by the Toyota
Production System (TPS), were:
1. Transport,
2. Inventory,
3. Motion (moving more than is required),
4. Waiting,
5. Overproduction,
6. Over Processing (from poor design), and
7. Defects (the effort involved in inspecting for, and fixing, defects).
CRITICAL SUCCESS FACTORS
The successful application of an agile methodology depends on the relative maturity of an
organisation in relation to Customer Engagement, Staff Resources, Technology, and
Processes. These measures are defined as follows:
 Customer Engagement – Product owners involved in teams daily activities, defines
requirements, drives the prioritisation of requirements, and has decision making
delegation of authority.
 Staff – have experience in an agile method, are skilled in the Standard Operating
Environment (SOE) toolsets, have an understanding of the underlying data and
technical infrastructure, and are conversant in the development, testing, and
configuration and release procedures.
 Technology – a stable and well documented technology stack, with clearly defined
ownership and service levels, providing discreet development, testing and release
environments that are sized and supported for the delivery of projects, and
controlled through rigorous configuration and release management.
 Processes – business processes exist for all domains, with cross stream
interdependencies defined and service levels agreed, and clear business ownership
and delegations of authority identified.

Notes:
COMMON MISCONCEPTIONS
Being a generic term, Agile means different things to different people. Therefore, before
we go much further, I should clarify some of the more common misconceptions
surrounding Agile.
 Agile is ad hoc, with no process control: First of all, Agile isn’t a lack of process.
Agile provides a range of formal processes, and methods, to inform work processes,
customer engagement and management models. Conversely, Agile isn’t about
blindly following the prescribed ‘agile’ methods and processes. Agile is about using
your common sense to apply processes, as determined by the current situation,
and shaped by the agile philosophy.
 Agile is faster and/or cheaper: Agile isn’t significantly faster, or cheaper, than
alternative frameworks. Put another way, in most cases you can’t get significantly
more effort out of your Teams by moving to an agile approach. While there is an
overall efficiency gain when utilising agile methods, well-managed Agile and non-
Agile Teams will deliver products and services in approximately the same time and
effort.
 Agile teams do not plan their work or write documentation: Agile is not an
excuse to avoid appropriate planning or writing documentation. It is an on-demand,
or Just-In-Time, approach that encourages continuous planning and documentation,
but only when needed for specific Customer Requirements. This allows Customers
and Teams to determine if the planning, or document, adds value to the process or
product. It creates an opportunity to emphasise valuable documents, and eliminate
anything that isn’t useful.
 An Agile project never ends: While this may be true in some situations, the benefit
of Agile is that work will continue while the Customer continues to gain business
value, and that value is worth more than the cost of developing it. Most projects, in
any industry, have a point of diminishing returns. This is the ideal time for an agile
project to end.
 Agile only works for small organisations: Agile works for projects, teams and
organisations of any size, not just small projects. That is not to say that it will work
for all organisations, but size is rarely a factor. Large and complex projects and
organisations are often excellent candidates for Agile transformation, where it is
difficult, or impossible, to know all your Customer’s Requirements in advance.

Notes:
 Without upfront planning, Agile is wasteful: This assumes that your Customer
knows the detail of all of their Requirements in advance. If this is true, then by all
means, undertake comprehensive upfront planning. However, in reality this is rare,
and usually leads to the greater ‘waste’ of having undertaken design and
development work that was ultimately unnecessary. Agile Business Management
encourages minimal upfront planning, ensuring everyone is working towards the
same goal, and reduces the risk of miscommunication.
 Finally, Agile is not the solution to all your problems. It is a change in approach
and culture that comes with its own set of benefits and issues.
SCRUM OVERVIEW
Scrum is described as a ‘framework within which you can employ various processes and
techniques’, rather than a process, or a technique, for building products. The Scrum
framework is primarily team based, and defines associated roles, events, artefacts and
rules. The three primary roles within the Scrum framework are:
1. The product owner who represents the stakeholders,
2. The scrum master who manages the team and the Scrum process
3. The team, about 7 people, who develop the software.
Each project is delivered in a highly flexible and iterative manner where at the end of every
iteration of work there is a tangible deliverable to the business. This can be seen in the
following diagram.
FIGURE 3: SCRUM FRAMEWORK

Notes:
The requirements that form the basis of the project are collated into what is called a
Project Backlog, and is updated regularly. The features that are associated with these
requirements are termed user stories. This relationship is illustrated in the following
diagram:
FIGURE 4: SCRUM PROJECT STRUCTURE
The work is time-boxed into a series of 1 to 4 week cycles where the business and project
team estimate which user stories in descending priority order are achievable each cycle, or
Iteration. This subset of user stories from the Project Backlog form the basis of the
Iteration Backlog planned for delivery over that two week period.
Under Scrum, there are 3 timeboxed (or fixed duration) meetings held during an Iteration
plus a daily stand-up meeting for the team, scrum master and (ideally) the product owner.
At the beginning of an Iteration, features to be developed during the iteration are decided
during the iteration planning meeting. At the end of the Iteration are another 2 meetings,
the Iteration review and Iteration retrospective where the team reviews the product and
demonstrates the use of the software, as well as reflect on, and improve, the Iteration
process itself.
After the iteration is complete, the next set of user stories is selected from the Project
Backlog and the process begins again. Burn rate is monitored to determine when funding
will be exhausted.

Notes:
TABLE 1: KEY SCRUM CONCEPTS
Concept Description
Project Discreet set of end user requirements that
have been grouped, prioritised and funded.
Requirement The end user statement that outlines their
information need.
Iteration (also known as a “Sprint”) An iteration is a 1to 4 week time-boxed
event focused on the delivery of a subset of
user stories taken from the Project Backlog.
Project Backlog The Project Backlog is the current list of user
stories for the Project. User stories can be
added, modified or removed from the
Backlog during the Project.
Iteration Backlog (also known as a
“Sprint Backlog”)
Subset of user stories from the Project
Backlog that are planned to be delivered as
part of an Iteration.
User Stories The user story is a one or two line
description of the business need, usually
described in terms of features.
Tasks Tasks are the activities performed to deliver
a user story.
Technical Debt This refers to items that were either:
 missing from the Planning meeting;
or
 deferred in favor of early delivery.
KANBAN OVERVIEW
The original concepts of Kanban (カンバン) were developed in the 1940s and 50s by Taiichi
Ohno as part of the Toyota Production System, as a mechanism to control Just-In-Time
(JIT) production and manufacturing processes. Kanban, which approximately translates as
‘signboard’, is described as a ‘visual process management system that tells what to
produce, when to produce it, and how much to produce’. The modern Kanban method, as
formulated by David J Anderson in 2007, is an adaption of the original JIT approach, with an
emphasis on staff welfare and continuous process improvement practices.

Notes:
FIGURE 5: AN EXAMPLE KANBAN BOARD
There are 6 core elements to Kanban:
1. Visualise (Card Wall)
2. Limit WIP
3. Manage Flow (and reduce bottlenecks)
4. Make Policies Explicit
5. Feedback Loops
6. Improve Collaboratively
The simplest visualisation of workflow has 4 different states which a task would progress
through during its lifecycle. These states are;
1. Iteration Backlog – ready to be worked on during the current iteration
2. In Progress – currently being developed by a team member
3. Testing – undergoing integration, system or UAT testing
4. Done – complete and ready to be demonstrated at the end of the iteration

Notes:
TEST DRIVEN DEVELOPMENT (TDD) OVERVIEW
Test-driven development is a development methodology that requires developers to create
automated tests before writing the code or function itself. If the tests pass, then the code is
displaying correct behaviour. These tests should be run automatically using one of the
xUnit applications.
There are 5 steps to TDD.
1. Create a test
2. Add the test to the test catalogue
3. Write the code
4. Run the tests (all of them)
5. Clean up the code as required. (Refactor)
FIGURE 6: TEST-DRIVEN DEVELOPMENT FLOWCHART

Notes:
EXTREME PROGRAMMING (XP) OVERVIEW
XP is an agile development methodology, intended to accept and respond to changing
customer requirements.
XP describes four basic activities within the software development process.
1. Writing the software
2. Testing the software, regularly and automatically
3. Listening and understanding the customer
4. Designing, or refactoring, an application framework to reduce unnecessary
dependencies between features.
XP also includes development methodologies such as;
1. Pair programming, with two developers working together
2. Common code standards (documentation, naming conventions, whitespace)
3. An understandable system metaphor, where all classes and functions names should
be understandable.
FEATURE DRIVEN DESIGN (FDD) OVERVIEW
FDD is a model-driven process that consists of five basic activities. For accurate state
reporting and keeping track of the software development project, milestones that mark the
progress made on each feature are defined.
PROCESSES
 Domain Object Modelling: Define the domain of the problem to be solved and
create an object framework.
 Developing by Feature: Functions are broken into the smallest possible part and
developed in the order of priority.
 Individual Class Ownership: Each code class is assigned to a single owner who is
responsible for the consistency, and performance of the class.
 Feature Teams: A small, dynamically formed team that designs and develops each
feature.
 Inspections: Carried out to ensure good quality design and code.

Notes:
 Configuration Management: A log of all features and the source code that have
been completed to date.
 Regular Builds: Ensures there is always a fully functional system.
ACTIVITIES
Develop Overall Model:
 High level scoping
 Create domain walkthroughs for each modelling area
 Peer review of each model
 Merge into complete system model
Build Feature List:
 Split domain into subject areas
 Separate subject areas into business activities
 Separate business activities into individual features
 e.g. Confirm the password of user
Plan by Feature:
 Assign features to classes
 Assign classes to developers (or development teams)
Design by Feature:
 Create a set of features to be developed within two weeks
 Build sequence diagrams for each feature
 Refine model for each feature
 Inspect and review the design
Build by Feature:
 Develop the code for each feature and class
 Unit test
 Promote to build

Notes:
PROJECT ROLES
‘So Mr Edison, how did it feel to fail 10,000 times?’
‘Young man, I didn’t fail, I found 9,999 ways that didn’t work’
Thomas Edison, anecdotal (on his invention of the incandescent light)

Notes:
PROJECT TEAM
The project team is a self governing group capable of independently delivering to a
customer’s requirements. As a result the team requires cross functional representation of
skills and knowledge in the data, tools and infrastructure domains.
A typical project team can be comprised of the following:
 Product Owner
 Scrum Master
 Architects / Analysts
 Designers
 Developers
The project team characteristics and responsibilities are as follows:
 7 ± 2 (5 to 9) resources who are allocated full-time to an Iteration
 Cross functional in nature across skills, applications, data and organisational
knowledge
 Self empowered
 Responsible for delivering the product
 Determine the tasks required to deliver each feature
 Estimate the effort for each task
 Develop the features
 Resolve issues
Ideally the project team, including the product owner are co-located.
INTERESTED AND COMMITTED
Interested roles are individuals who have an “interest” in the software development. Whilst
they should be kept informed of progress, they do not have the same level of responsibility
and input into the development as committed roles. Interested parties include the Users,
the Customers and the Product Owner.
Committed roles are responsible for the software development, and are the people who
“do” the work. Committed parties include the Scrum Master, the Team and Testers.

Notes:
FIGURE 7: PIGS AND CHICKENS
PRIMARY ROLES
FIGURE 8: BUSINESS VS TECHNICAL ROLES

Notes:
TABLE 2: PRIMARY SCRUM ROLES
Role Primary Responsibility Typical Does Not
Users
Interested Role
 Use the software
 Identify issues &
 Provide feedback
 There are no typical
users.
 Set Scope
 Test Work
Customers
Interested Role
 Define, start and end
the project
 Internal managers
 External Clients
 Direct Work
Product
Owner
Interested Role
 Manage the product
backlog
 Set the scope
 Approve Releases
 Project Manager
 Product manager
 Customer
 Manage the
Team
Scrum Master
Committed
Role
 Manage the Agile
process
 Report on progress
 Project manager
 Team Leader
 Team member
 Prioritise
features
Developers
Committed
Role
 Develop features
 Resolve issues
cross functional
 Developer
 Designers
 Writers
 Administrators
 Prioritise
features
Testers
Committed
Role
 Test
 Approve or reject
features for release
 Existing developers
 Dedicated testers
 Test their own
code

Notes:
PROJECT INITIATION
aka Feasibility
aka Sprint 0 (Scrum)
aka Iteration 0 (XP)
‘It is always wise to look ahead, but difficult to look further than you can see.’
Winston Churchill, ~1960

Notes:
SPECIFICATIONS IN AGILE?
Contrary to common opinion, it is very important to have a good specification before
starting an agile project. By building this specification (or backlog in agile terminology) a
project will;
 Reduce Risk & Uncertainty
 Improve Decision Making and integrate With Long term Goals
 Improved cost planning (including Staff Hiring)
 Prioritise research and information Gathering
BEGINNING THE PROCESS
Unlike traditional waterfall methods, the specification phase of an agile project is very
short; usually no more than 1 or 2 days, and the full team should be available at inception.
During the period the customer should be made fully aware of their role. The design
should contain the following;
 Problem statement that needs to be addressed
 Desired business objectives, outcomes and benefits for this project
 Identified key stakeholders
 High Level Business Requirements
 Architectural and technical scope
 Testing requirements
OUTCOMES
The outcomes from Project Initiation, or Iteration 0, are:
 The team should be identified and brought together
 If not part of the team, identify and train the product owner
 Create the product backlog in low detail. Allow customers to slowly build the
product requirements throughout the process.
 Estimate the product backlog.
 Plan length of the iteration, anywhere from 1 day to 4 weeks. Each iteration should
accomplish something releasable. Short iterations short can reduce overtime.
 Add any team training to the backlog as tasks.

Notes:
BACKLOG
FIGURE 9: PRODUCT BACKLOG
The backlog contains all the user stories (features) for the product. The Product Owner is
responsible for defining the user stories, and assigning each with a priority for delivery.
The order may also be influenced by story dependencies or business value e.g. a lower
priority story may need to be done first before a higher priority story can be started.
The user stories describe the set of features that will satisfy each requirement. The high
priority user stories that are candidates for the next Iteration require sufficient detail for
the team to solution, and should be sized to fit within two weeks.
Each user story should meet the INVEST characteristics, as defined by Bill Wake.
 Independent: Each Requirement should be as self-contained as possible, with
minimal dependencies on any other Requirement. This allows for easy reordering
or removal, as Customer Requirement’s change.
 Negotiable: The Customer can change a Requirement at any time, up to the point it
enters the Iteration Backlog.

Notes:
 Valuable: Each Requirement should deliver a tangible, and measurable, benefit to
the Customer.
 Estimatable: The definition of each Requirement is such that the Team can estimate
it.
 Small: The estimate, and delivery, of a Requirement, should be within a few days, or
a single Iteration.
 Testable: Each Requirement should have appropriate quality control and quality
assurance metrics, so the Customer can validate their Deliverables against the
original Requirement.
Each feature should contain, at a minimum, the function, priority, an estimate of the effort
to develop and the estimate risk (0 - 100%) based on how accurate the team feels the
estimate is.
In can be helpful to structure each user story in the following format.
As a [role]
I want a [goal/desire]
So that [benefit]
The [role] is the expected end-user of the user story, who is usually different from the
Customer. The [goal/desire] of each user story describes what should be delivered, and the
[benefit] provides the context, or the Why.

Notes:
ACCURACY
FIGURE 10: ESTIMATE ACCURACY OVER TIME
It is important to note that to increase the accuracy of any estimate, the effort involved
increases exponentially. In Agile, we are only interested in the initial estimation.
By keeping Iterations short, we can better review and respond to deviations in the estimate
quickly. See the Burndown chart section for more information.

Notes:
ESTIMATING EFFORT
STORY ESTIMATION
A Story Point is single number intended to represent all of the work required for the whole
team to build the final product. As a result, to perform estimation based on story points it
requires cross functional representation of all the requisite skills and knowledge in the
systems, data, tools and infrastructure during the Iteration Planning meeting.
Story points are used for the high level estimation of user stories. They are usually based
on the delivery of similar user stories in previous Iterations. This assumes that the project
team, systems and infrastructure are relatively constant between one project and the next.
The size of a Story point for a given project team will eventually normalise over time.
All stories should be assigned as estimated effort, or cost, to implement. We use a modified
Fibonacci series, such as 1, 2, 3, 5, 8, 13, 20, 40, and 100, to represent effort. This
encourages features to be split into the smallest task possible, and provides a more
realistic estimate range.
TASK ESTIMATION
Task estimation is performed at the Iteration level. During the Iteration Planning session
the team breaks the user stories into their composite tasks to determine how they will be
delivered. The process of solution decomposition may reveal additional tasks, or more
complex tasks that were not apparent during the high level story point based estimation
that impact what was planned to be delivered. The scope of the Iteration can be
renegotiated with the product owner if this is the case. Unlike story points, these estimates
are an indicative idea of how much time they will take in an ideal world.
HOW?
Tasks can be estimated in 4 ways.
1. Expert opinion: The team member with specific understanding, or who is most
likely to develop the task, can provide a more accurate estimate of effort.
E.g. A database administrator can better estimate effort for database tasks.

Notes:
2. Comparison: Comparing a task to another, already estimated, task.
e.g. "Task A is about twice the effort of Task B"
3. Components: If a task is too large to accurately estimate, break it into small sub-
tasks.
e.g. User management can be broken into interface, login, ACL, etc.
4. Planning poker: If using Planning Poker, estimates must not be mentioned at all
during discussion to avoid anchoring. A timer may be used to ensure that
discussion is structured; any person may turn over the timer and when it runs out
all discussion must cease and a round of poker is played.
Each person lays a card face down representing their estimate of the task, and then
simultaneously turns their cards over.
People with high estimates and low estimates are given an opportunity to discuss
their estimate before anyone else can speak.
Repeat the estimation process until a consensus is reached.
FIGURE 11: PLANNING POKER CARDS

Notes:
ESTIMATING TIME
Converting an estimated cost into estimated time is very simple. There are 2 primary
modifiers that we use. Staff overhead and estimate accuracy (or risk).
STAFF OVERHEAD
This is a percentage modifier for staff availability to work on specific project tasks. It allows
you to take into account factors such as estimated leave, illness, breaks, scrum meetings
etc. The industry standard modifier is 25%-40%, though you should modify this as
required. To calculate staff overhead use the following process;
working hours = (hours per day * days per iteration * staff) – planned leave
project hours = sum of actual (from last iteration)
staff overhead = (working hours/project hours) – 1
CALCULATION
Story Cost x (Staff Overhead + 1) x (Estimate Risk + 1)
e.g.
4 x (25%+1) x (50%+1)
= 4 x 1.25 x 1.5
= 5 to 7.25 hours

Notes:
COST / TIME / SCOPE
“How much is this going to cost?” - “As much as you're willing to spend.”
“How long is this going to take?” - “As long as it necessary.”
“What am I going to get?” - “Whatever you tell us you want.”
FIXED COST
Where a customer asks for a fixed price quote prior to agreeing to project commencement,
but is flexible on what is delivered and how long it takes.
 Work in absolute customer priority order – reducing the time spent on technical
helper tasks will help meet short-term budget constraints (at the cost of long term,
post-project, efficiency)
 Release in short (1-2 week) iterations – similar to longer waterfall projects, longer
iterations have a tendency to cost overruns to deliver on time
 Monitor velocity and burn rate – this is your key indicator of cost
FIXED TIME
Where a customer asks for delivery by a certain date, but is flexible in scope and cost.
 Work in absolute business value order – increases the number of user stories
complete in a given iteration (high business value = simple, moderate-high priority)
 Enforce iteration duration – Your project will be defined by a fixed number of
iterations, and extending an iteration will push out your final date
FIXED SCOPE
Where a customer asks for a fixed set of deliverables, but is flexible in the time it takes to
deliver and the cost of delivery. This is sometimes known as “heavy agile”.
 Focus on backlog definition and estimation during Iteration 0 to ensure accurate
scope definition

Notes:
FIXED COST AND SCOPE
Where the customer asks for a fixed price quote for a fixed set of deliverables. In this
situation, the final date for delivery is flexible. As well as the points in fixed cost and fixed
scope;
 Increase the estimate risk during Iteration 0 – to ensure your quote for the project
allows for unexpected delays (which would impact on your cost to deliver)
 Update delivery date as required
FIXED COST AND TIME
Where the customer asks for a fixed price quote by a fixed time. In this situation, the exact
set of features (or scope) for delivery is flexible. As well as the points in fixed cost and fixed
time;
 Calculate total cost as cost per iteration – which makes your quote to the customer
very simple.
FIXED TIME AND SCOPE
Where the customer asks for a fixed set of deliverables by a fixed time. In this situation, the
total cost to the customer is flexible. As well as the points in fixed time and fixed scope;
 Pre-assign work to iterations during Iteration 0 – which will define the scope
delivery timetable.
 Pad schedule with extra iterations – to cater to unexpected defects or technical debt
 Increase the size of the team 3-4 iterations prior to the end of the project if
required – to ensure the set of features are completed in time.
FIXED COST, TIME AND SCOPE
Where the customer gives no flexibility in the project.
Cancel the project – this is not an agile project. This should be run using a waterfall
methodology such as PRINCE2 (and even they are likely to fail without some flexibility)

Notes:
STARTING AN ITERATION
‘Make everything as simple as possible, but not simpler.’
Albert Einstein (paraphrased), 1933

Notes:
FIGURE 12: EXAMPLE BUSINESS PROCESS FLOWCHART

Notes:
ITERATION PLANNING MEETING
FIGURE 13: ITERATION PLANNING
The Iteration Planning Meeting is run before the start of each Iteration, and allows the
customer and developers to discuss the requirements and work required for the next
release. This step in the Scrum process focuses on determining the target scope of delivery
for an Iteration, and defines the iteration backlog. The Iteration Planning Meeting should
be no more than 8 hours long (4 weeks pro rata).
The Product Owner and Scrum Master are responsible for updating the Project Backlog in
preparation for the Iteration Planning meeting. This includes clarification, prioritisation
and in some cases investigation of the feasibility of the collated user stories. This activity
also needs to take into consideration any technical debt inherited from previous Iterations.
PART 1 – BUSINESS SPECIFICATIONS
The first part of the iteration planning meeting aims to convert features from the backlog
into a realistic goal for this iteration. The product owner is a part of this process and sets
the priority of the tasks. This also provides the Product Owner with the opportunity to
communicate the required scope of delivery, provide the business context and priority, and
address any questions the project team may have to assist with performing the solution

Notes:
decomposition and estimation steps. This part of the meeting should take no more than ¼
of the time.
Ensure that a copy of the Project Backlog has been distributed prior to the Iteration
Planning meeting to provide the project team with time to consider solution options for
discussion during the workshop, and prepare clarification questions for the Product
Owner.
The participants for this session are as follows:
 Product Owner
 Scrum Master
 Team
 Testers
PART 2 – TECHNICAL SPECIFICATIONS
The second part of the Iteration Planning meeting is technical, and usually without the
product owner. This is the solution decomposition and estimating step in the planning
process and aims to estimate the effort for all features in the release and (optionally) write
the test cases.
The general flow of activity in this step is described in the following diagram:
FIGURE 14: DESIGN AND PLANNING WORKFLOW

Notes:
As a guideline, large tasks should be broken into tasks preferably no longer than 1 day and
tasks that involve waiting should be split into separate tasks. Research tasks should have a
high estimate risk. This is done to enable accurate tracking and the calculation of velocity.
For complex user stories or those with a high number of interdependencies it may be
necessary to split the task decomposition and estimating activities across 2 days and allow
the team members an opportunity to consult with external parties on feasibility and obtain
input into the estimating process.
Always remember that tasks can be created, but features can't.
 Scrum Master
 Team
 Testers
TABLE 3: KEY PLANNING ELEMENTS
Planning Element Description
User Story The user story is a description of the
business need, usually expressed as a
feature.
Story Identifier Every user story will be assigned a unique
identifier for tracking purposes.
Task A task is typically a single activity that can be
described in one sentence that contributes
to the delivery of a user story.
 Generally a task takes no longer than 4-8
hours of effort to complete
 There may be one or many tasks per
user story
 The task can only be assigned to and
owned by one person at a time
Task Identifier A Unique identifier will be assigned to track
each task, and show which user story they
are associated with.
Project Function This describes the architectural layer where
the task activity will be performed.

Notes:
Assignee This is the person who will be responsible
for delivering the task. This can done at any
point in the Iteration. The person assigned
to the completion of the task may also
change at any point in the Iteration.
Estimate The estimate in hours is the amount of
effort the team agrees is required to
complete the specified task. The estimate
includes:
 Analysis
 Build
 Unit Test
 Migrate from DEV to TEST
 Integration Testing
 Documentation
Estimate Risk Modifier This is a measure of the confidence level
associated with the estimate provided and
represented as a numeric modifier.
NOTES
 Prepare beforehand.
 This is a creative, problem solving process. Encourage brainstorming.
 Ensure the planning room has plenty of paper, a whiteboard and a computer with
Google access.

Notes:
DURING AN ITERATION
‘Treat your men as you would your own beloved sons. And they will follow you into
the deepest valley.’
Sun Tzu, ~6th Century BCE

Notes:
DAILY LIFECYCLE
The daily lifecycle of team activities is as follows;
1. Team members select the next task to work on
2. Undertake the task as described
3. Commit and share the completed task with the rest of the team
4. Write and run the tests that will be used to verify they have been completed
successfully. Verification, unit testing and documentation need to be completed
prior to migrating the deliverable from DEV to SIT.
The assignee for a task may change at any of these steps. Team members will proactively
interact will their colleagues and any internal parties as required to progress the assigned
task to completion, including any quality assurance and review.
The governance of the daily lifecycle is through the daily Scrum Meeting.
FIGURE 15: WORK LIFECYCLE

Notes:
TASK LIFECYCLE
Based on Kanban, a task will progress through a minimum of 4 different states during its
lifecycle. Each task and state should be visible to the team, product owner and customer;
commonly this is done through a card wall or integrated dashboard.
FIGURE 16: BASIC TASK LIFECYCLE
FIGURE 17: COMPLEX TASK LIFECYCLE

Notes:
ITERATION BACKLOG
The Iteration Backlog is the subset of user stories from the Project Backlog that the Product
Owner and project team agreed would be delivered for this Iteration.
The user stories will be broken into tasks which are put into the Iteration Backlog. Based on
the logical sequencing of tasks and agreed prioritisation, the project team members select
the next task to work on and promote this to the “In Progress” state.
IN PROGRESS
In Progress items are tasks that are actively being worked on. This includes both
development and unit testing activities. Once the task has been completed it is promoted
to the “Testing” state.
In Progress tasks include the following types of activity being performed:
 Analysis
 Build
 Unit Test
 Documentation
When a task has been completed the deliverable will be changed to the “Testing” state. In
the case of code based artefacts these will be promoted from the development
environment to the test environment.
BLOCKED
Blocked items are stories and or tasks that have upstream or downstream dependencies
external to the project team that are preventing progress. These impediments are moved
to this holding state to highlight these issues to the Scrum Master and Product Owner for
escalation and resolution.
TESTING
Testing, in this context, is performed by the team’s specialist testing resources. Unit testing
is expected to be undertaken by the developers.
DONE
Tasks are considered “Done” when:

Notes:
 Code has been produced, meets development standards, and has been checked in
and run against current version in source control
 Unit tests written and passed
 System tested and passed
 Quality Assurance reviewed
 Builds without errors for deployment
 Relevant documentation, including diagrams have been produced or updated and
communicated
When the Iteration has completed the user stories selected by the team to be delivered are
either “Done” or “Not Done”. The decision over whether a user story is Done is based on
whether all the pre-requisite tasks associated with this story have been completed. The
completed user stories are presented to the Product Owner in the Iteration Review for
acceptance and sign-off.
NOT DONE
Tasks that are “Not Done” are reviewed in the context of the user stories that they belong
to and if this impacts whether the user story can be considered delivered. The not done
tasks may be rolled into a new user story for the next Iteration, accrued as technical debt,
or it may be decided that they are no longer required and are removed.
DEVELOPMENT HINTS
FEATURES
Get the highest priority feature from the Iteration backlog. Allow developers to choose
their work, don't assign it. The backlog can be updated mid-iteration if critical changes are
required.
DEVELOP
Agile also makes some suggestions on improving the development process. These are;
 Pair Programming: Two developers working together, the first as a coder and the
other as a reviewer. These roles should change regularly, and the pairs themselves
should switch pairs each day
 Code Standards: A common coding style (Documentation, Names, Whitespace, etc)
 System Metaphor: All classes and functions should be named such that their
purpose is understood.

Notes:
COMMIT
Everyone must commit every day, and should never commit broken code. (Continuous
Integration)
TRANSPARENCY
Key to Agile is transparency between the product, the team and the customers.
Customers can:
 Attend scrums. However they should not talk. Questions should be directed to the
Product Owner or Scrum Master. An alternative is to record the scrums and make
the recording available to the customer.
 See the product and iteration backlog in its current state.
 See the state of each task via a card wall or integrated dashboard.
 Access a test version of the software from the development environment.
TEST DRIVEN DEVELOPMENT
KEY POINTS
Tests are written by the Customer and Developer together and are written before the code.
Both automated unit tests and user acceptance tests should be written. There is no issue
with using standards such as IEEE 829 and IEEE1008 to document and write tests.
By using TDD, the team can prove how well a project is going and how close to completion.
This in turn, allows customers and product owner to make informed decisions about the
project.
TEST COVERAGE
The tests should cover;
 Software functions,
 Boundary cases,
 User interface,
 User experience,
 Non-functional components,
 Performance

Notes:
TEST TYPES
There are 4 types of tests that can be written.
1. Defect
2. Functionality
3. Usability
4. Data
TDD IN DEVELOPMENT
FIGURE 18: TDD WORKFLOW
CONTINUOUS INTEGRATION
UNIT TESTING
Runs predefined tests to identify software defects
 Create tests for each class and function
 Create tests for all parameter combinations
 Create tests for all edge cases
 Create tests to examine the database for logical errors
 Create tests to detect interface defects (Selenium)
 Tests should be kept in the version control repository
 Test in a clone of the production environment

Notes:
FIGURE 19: UNIT TEST SCREENSHOT
CODE STANDARDS
Inspect the developed code for deviations from the internal code standard
 Check for correct inline documentation (docblock)
 Check for correct variable naming conventions
 Check for correct whitespacing conventions
 Check for complex code that may require refactoring
 Check for incomplete or unused functions
FIGURE 20: CODE STANDARD SCREENSHOT

Notes:
DOCUMENTATION
The following should be commented;
 Files
 Classes
 Functions
 Class Variables
 Complex Structures
Comments should contain;
 Description
 Author
 Usage
 Parameter description
 Return description
 References to other functions
 Copyright (file comments)
CODE COVERAGE
Calculate and display how much of the software is covered by unit tests. Aim for 80-90%
code coverage.
FIGURE 21: CODE COVERAGE SCREENSHOT
COMPILE
Run any compile or make scripts. All commits should compile.

Notes:
SCRUM MEETING (AKA DAILY STAND-UP)
The purpose of the daily stand-up meeting is to provide a consistent focus on incremental
progress and delivery demonstrated to the Product Owner. It is intended to be informative
and interactive and align the team’s understanding of what is being worked on, by whom
and its current status.
This meeting consists of the Product Owner, Scrum Master, and the project team and is
time-boxed to 15 minutes.
All participants should answer the following three questions:
1. What did you achieve yesterday?
2. What will you achieve today?
3. What impediment may prevent you from achieving your goal today?
It is the objective of the BI Scrum Master to remove any impediment identified by the
team.
FIGURE 22: DAILY STANDUP WORKFLOW
Projects with multiple teams should hold a scrum of scrums, also timeboxed to 15 minutes,
after the initial scrums. This meeting should bring together Scrum Masters from multiple
teams to answer the same 3 questions as before, but relating to their teams.

Notes:
INSPECTION
PROJECT VELOCITY
Project Velocity is a measure that determines the capacity and resulting output from the
project team over time. In this case it refers to how many user stories the project team
estimate that they can deliver in the project.
The methods available to determine Project Velocity are as follows:
 Use historical values - this assumes similarity between previous user stories in
terms of relative size, data, infrastructure etc
 Run an Iteration – derive the estimate based on observed Velocity over 2-3
Iterations
 Make a forecast – this approach is used where we do not have existing historical
values and it is not feasible to run several Iterations to observe the team’s velocity.
User stories are disaggregated and estimated at a task level.
The scope of the project, any changes to the scope, and the planned and actual delivery of
user stories can be represented in a burndown or burnup chart. This chart can also be
used to forecast when the project team will have completed all the user stories in the
Project Backlog.
ITERATION VELOCITY
Effort based Velocity determines the capacity and resulting output from the project team
for a given Iteration i.e. how many user stories can be delivered over the next two weeks.
This velocity can be calculated as an average at the team level, or if there is a significant
variation in the working hours as an aggregate of the individuals.
Iteration velocity is measured in terms of Potential and Forecast capacity:
 Potential Iteration Velocity is the sum of allocated working hours for the project
team
 Forecast Iteration Velocity is the estimated productive workable hours that can be
attributed to Iteration tasks i.e. takes into account Staff Overhead

Notes:
BURNDOWN & BURNUP CHARTS
FIGURE 23: EXAMPLE BURNDOWN CHART
Burndown and Burnup charts help managers and customers to view progress against the
release, improve future estimates and identify problem trends early. The Burndown (or
burnup) chart should be available to everyone involved in the project.
FIGURE 24: EXAMPLE BURNUP CHART

Notes:
PROGRESS PROBLEMS
All about risk mitigation
DISCOVERY
FIGURE 25: PROBLEM BURNDOWN (DISCOVERY)
Issues identified after the iteration begins or refined estimation after the iteration begins.
Watch the progress carefully. If necessary review the tasks in the Iteration
SCOPE CREEP
FIGURE 26: PROBLEM BURNDOWN (SCOPE CREEP)
Tasks are being added mid-release. Identify who is adding tasks and stop this behaviour.

Notes:
PLATEAU
FIGURE 27: PROBLEM BURNDOWN (PLATEAU)
Features are more difficult than estimated or unexpected staffing issues. Review the tasks
in the iteration.
TOO MANY FEATURES
FIGURE 28: PROBLEM BURNDOWN (TOO MANY FEATURES)
Features are more difficult than estimated. Review the estimation process and remove
tasks from the iteration.

Notes:
TRACKING EPICS
FIGURE 29: PROBLEM BURNDOWN (TRACKING EPICS)
Individual stories are too large and difficult to track. Keep each task under 1 day of work.

Notes:
FINISHING AN ITERATION
‘Fall seven times. Stand up eight.’
Old Japanese Proverb

Notes:
ITERATION REVIEW
After the Iteration, the Scrum Master should hold an Iteration Review meeting to
demonstrate to the Product Owner and Customer (if different) the completed user stories
for final review for release to production. As the Product Owner should have been
involved in the development and verification process on a daily basis this step should be
straightforward.
 Product Owner
 Scrum Master
 Project Team
During the meeting the team should:
 Present the completed work to the Product Owner
 Review the work that was completed
 Review the work that was not completed. The user stories that were not completed
may move to the next Iteration.
FIGURE 30: ITERATION REVIEW

Notes:
KAIZEN AND THE ITERATION RETROSPECTIVE
After the Iteration Review, the Scrum master should hold an Iteration Retrospective
meeting to discuss and improve on the Iteration process itself. During this meeting the
team should;
1. Reflect on the iteration
2. Make any process improvements
3. Discuss what went well during the iteration
4. What could be improved during the iteration
The Iteration Retrospective provides the team with the opportunity to reflect on the
Iteration just completed and drive continuous process improvement out of the learning’s
taken from this.
FIGURE 31: ITERATION RETROSPECTIVE

Notes:
REFERENCES

Notes:
BOOKS & LINKS
Directing the Agile Organisation – Evan Leybourn
Agile Estimating and Planning - Mike Cohn
Managing Agile Projects - Kevin J. Aguanno
http://en.wikipedia.org/wiki/Agile_software_development
http://agilemanifesto.org/
http://en.wikipedia.org/wiki/Agile_testing
http://en.wikipedia.org/wiki/Scrum_(development)
http://www.ambysoft.com
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
http://en.wikipedia.org/wiki/Agile_software_development
http://www.agileadvice.com/
http://en.wikipedia.org/wiki/IEEE_829
http://www.ddj.com/architect/201202925?pgno=4
http://www.scrumalliance.org
TOOLS
http://trac.edgewall.org/
http://watir.com

Notes:
SUPPORTING MATERIAL – EXAMPLE RELEASE AND TEST
MANAGEMENT PLAN

Notes:
Design Document
Requirements
Gathering
Includes Produce Owner
discussions during the previous
release
Development
Design Meeting
Release Design
Document
Includes Testing Document
PO Signoff
Development
Update Meeting
Create Tasks in
Trac & Assign to
Developers
No Yes
Development
Includes Daily Scrums & DEV updates
Mid-Cycle
Requirement
Code FreezeTesting
Tests Pass
Priority FixResolve Issues
Release Approval
Document
PO Signoff
Uncompleted
Tasks
Add Uncompleted
Tasks to Next
Release
Release to
Production
Design Document
Appendices
No
Yes
Yes
No
Yes
Yes
No
No
Release Design
Document
Appendices
Yes
External
Announcements
Post Production
Testing
Tests PassNo
Migrate DEV to
TEST
Rollback
SCHEDULE OF ACTIVITIES & DESCRIPTION OF THE APPROVAL PROCESS
This is an example process for a monthly iteration cycle.
Requirements
Documentation
Product Owner Processes

Notes:
Process Description Timeframe Responsible
Design Document The base design document. This outlines all baseline
features in <Product> when initially released.
Complete Technical
Lead
Requirements
Gathering
Requirements are drawn from user and product owner
feedback during the previous months. The priorities are
set by the product owner which leads to the
development design meeting.
Ongoing Technical
Lead
Development Design
Meeting
A half day meeting of the development team to discuss
the requirements and to decide on the resources and
timeframes involved.
Day 1 Development
Team
Release Design
Document
A formal document outlining the features that will be
developed during the next sprint. Not all requirements
(from step 1) will be part of the release.
Day 1-2 Technical
Lead
Product Owner
Signoff?
Does the product owner approve the design document? Day 2 Product
Owner
Development Update
Meeting
A short meeting of the development team to resolve any
design issues raised by the Product Owner and hindering
signoff.
Day 2 Development
Team
Create Tasks in
management system &
Assign to Developers
After the design document is complete, the features are
broken down into short tasks and assigned to developers
to complete.
Day 3 Technical
Lead
Development The development of <product>. Progress is measured
through daily scrums and review of the tasks.
Updates to <product> are regularly migrated to the DEV
server. Issues in newly developed code are added as
defects.
Approximately
20 days
Development
Team
Mid-Cycle
Requirement
Gathering
These are high priority requirements, drawn from user
and product owner feedback during the development,
and form part of the current release cycle.
Product
Owner
Release Design
Document Appendices
Appendices to the formal design document outlining any
mid-cycle requirements.
Technical
Lead
Code Freeze No new features can be developed during this release
cycle. The developers will continue to work on
defects/bugs in <product>. Any requirements from the
design document which are incomplete are moved to the
next release.
Day n-5 Technical
Lead

Notes:
The product owner can choose to extend the current
release cycle if the requirements warrant it.
Migrate DEV to TEST Migrate all changes from the DEV server to the TEST
server for formal testing
Day n-5 Development
Team
Testing <product> testers run the base test cases and any new
test cases to identify issues and defects in the current
release.
Day n-5 Testers
Tests Pass? Were the tests successful? Day n-5 Testers
Priority Fix? Are the issues raised in testing minor, and can they be
delayed until the next release?
Day n-5 Technical
Lead
Resolve Issues Any issues or defects for the current release are resolved
by the developers, which then get re-tested.
Day n-3-4 Development
Team
Release Approval
Document
A document based on the initial design document which
outlines all completed features in the current release.
Day n-2 Technical
Lead
Uncompleted Tasks? Are there any features from the original design
document which could not be completed in the current
release?
Day n-1 Technical
Lead
Add Uncompleted
Tasks to Next Release
To form part of the next design document. Day n-1 Technical
Lead
Product Owner
Signoff?
Does the product owner approve the current release Day n-1 Product
Owner
External
Announcements
Send an email to all <product> users describing the new
changes to <product> with the updated user manual.
Day n-1 Technical
Lead
Backup Current
Production
Make a manual backup of the current production
release. This is used if the system needs to rollback after
the release.
Day n-1 CIO Division
Release to Production Migrate the changes from TEST to PROD Day n CIO Division
Post Production
Testing
Run through a series of tests to ensure the production
release was successful.
Day n Testers
Test Pass? Were the post production tests successful? Day n Testers
Rollback Revert PROD to previous release. Day n CIO Division
Design Document
Appendices
Appendices to the base design document outlining the
changes to <product> that were made in the current
release.
Day n+1 Technical
Lead

Notes:
ROLES, RESPONSIBILITIES AND RESOURCE REQUIREMENTS
Name Role Responsibility
<Name> Product Owner Final approval for release
<Name> Technical
Manager
Sign off of issues / tasks within the scope of the
release
<Name> Scrum Manager Manage the daily scrum and monthly design meeting
Testers (Various) Tester Follow test cases to identify issues. Can pass/fail cases
at their discretion
<Name> Infrastructure
Lead
Maintaining the Development, Test, and Production
hardware
Install software onto Production hardware
Run post-release deployment tests to confirm
successful deployment
Formal testers must have had training in using <product>, but should not be “power
users”. That is, highly skilled users often miss the usability issues that a “casual user” can
identify. For the same reasons, software developers cannot be testers.

Notes:
ROLL BACK STRATEGY
Rollback occurs if the post-production testing identifies any major issues. It is for this
reason that post-production testing occurs as soon as possible after the migration from
TEST to PROD. The process is as follows;
1. Take a complete backup of the current production application. This includes the
application data, and the database.
2. Migrate the new version from the Test server to the Production server.
3. Post-Production testing runs through a series of tests to ensure the production
release was successful. These tests include;
a. Comprehensive tool testing to ensure each tool operates as expected.
b. Speed testing to ensure that each tool (specifically mapping and charting)
are responsive within the allowed times.
c. Authentication testing to ensure that administrators and normal users can
access <product> appropriately.
d. Data quality testing to ensure that the <product> database was updated
correctly.
4. If the tests did not pass, and the issue can’t be resolved quickly in-situ, begin the
rollback process;
a. Obtain permission from the Product Owner to rollback.
b. Replace the new version of <product> with the recent backup, including
application data, the mapping files and the database.
c. Email all <product> users informing them of an issue and that the expected
upgrade will take place at a later time.
d. Review the issues with the Product Owner and Development Team to
identify what caused the issue and why it was not picked up in initial testing.

Notes:
TESTING METHODOLOGY
TEST DRIVEN DESIGN METHODOLOGY
The <product> testing methodology is based on “Test Driven Design Methodology” (TDD),
which is part of the Extreme Programming practices. The core of the methodology is that
the basic tests are developed before the software is written.
Write Test Cases Write Code
Yes
No
Test Passes
A major part of TDD is “Unit Testing”, a series of automated tests which thoroughly search
for logical errors in the software whenever a function is completed. These tests are
constantly built on previous tests so if something developed six months ago suddenly
breaks under a new update, it is known immediately.
See http://www.developer.com/design/article.php/3622546 for more information
TESTING DETAILS
Testing is performed by <who> staff. These are people who are familiar with the system,
but are not involved in the development process.
When a release is scheduled all current test cases are loaded into the issue management
system by the Technical Lead. These test cases are assigned to the testers on a random
basis and each tester is given a short session discussing what changes have been made and
what they should expect.
As each test is completed, the tester updates the test case as either “passed” or “failed”.
Failed tests are reviewed by the Technical Lead who either accepts the failure or assigns a
defect to a developer to resolve the issue. Once resolved the failed test case is reassigned
to the original tester to re-test.
Further information can be found under the “Test Report Template” section of this
document.

Notes:
TEST TYPES
There are four forms of tests which are run.
1. Defect Testing - Are there any bugs or defects that have been missed?
2. Functionality Testing - Does the release meet the original requirements
specification?
3. Usability Testing – Is the release user friendly?
4. Data Testing – Is the data in <product> reasonable and suitable as a policy evidence
base?
MANUAL TESTING
All tasks in <product> are managed using a test management tool, including test cases.
Each test case is linked to a category and a milestone in which to complete it (e.g. May
Release). These test cases are then assigned to a tester to run and go through the following
workflow;
 New (Test cases are created)
 Assigned (Test cases are assigned to a tester)
 Tested (Test cases have been run and are awaiting review)
o Failed test cases go back to assigned once the underlying issue is resolved.
 Closed
AUTOMATED TESTING (UNIT TESTS)
The continuous integration environment runs unit tests for every software update and
informs the developers if they have introduced a new defect. If a unit test fails, the
responsible developer is notified immediately and the update is removed from the current
version until is passes.

Notes:
MAPPING BETWEEN THE TEST SCRIPTS AND THE REQUIREMENTS
As per the development process, basic test cases are developed during the initial design
phase. These test cases are further refined during the development cycle as specific
functionality is created. This process ensures a close mapping between the test scripts and
the requirements.
Test Case
Catalogue
Release Design Document
Release Design
Document
Release Test
Cases
Release Test Run
Add to Test Case
Catalogue
Development
Update Test
Cases
There are two exceptions to this process.
1. Tests developed prior to this process. These tests form part of the catalogue to
ensure good coverage of the test scripts.
2. Core tests that relate to underlying functionality. Underlying functionality is a
product of the design process, and does not map to a design requirement.

Notes:
TEST REPORT TEMPLATE
There are 6 details that make up a test case.
1. Reported By: Who is managing the test case? This person is responsible for verifying
the result and managing the resolution of any issues arising from failed test cases.
2. Owned By: Who is the test cases assigned to?
3. Priority: How important is this test case?
4. Milestone: Which release is this test case for? Each Milestone in Trac is a monthly
release.
5. Component: What part of <product> is the test case for?
6. The description of the test. This is broken into numbered steps. There can be many
verifications in a single test, and if any of them fail the entire test fails.
Note that test cases don’t use time estimation.
SAMPLE TEST CASES
These testcases are written by the developers and loaded into the tracking system during
each testing period.
Summary Test
<Test Summary> 1. Log in to <product>
2. Select <something>
3. Verify <results>

Notes:
SUPPORTING MATERIAL – EXAMPLE HIGH-LEVEL
BUSINESS REQUIREMENTS

Notes:
GLOSSARY OF TERMS
Term Definition
<Term> <Definition>
INTRODUCTION
OBJECTIVE
<What Is The Objective Of This Product>
NEED/PURPOSE
<What Need Or Purpose Does It Fulfil>
USAGE
<Who Is The Target Audience / Who Is Allowed To Access The Product>
SCOPE OF REQUIREMENTS SPECIFICATION
INCLUSIONS
<What Is Included In The Specification>
EXCLUSIONS
<What Is Not Included In The Specification>

Notes:
FUNCTIONAL REQUIREMENTS
GENERAL
ID Requirement description Essential
or
Desirable
1 Essential
REPORT GENERATION & PRINTING (INCLUDING MANAGEMENT INFORMATION)
or
Desirable
1 Essential
HELP FACILITIES
or
Desirable
1 Online help will be available Essential
2 Context sensitive help for users Desirable
3 Tooltips will appear on mouse-over of objects Essential
4
SYSTEM MANAGEMENT
or
Desirable
1 Desirable
NON-FUNCTIONAL REQUIREMENTS
GENERAL
or
Desirable
1

Notes:
SECURITY
or
Desirable
1 The product will adhere to Open Web Application Security Project
(OWASP) standards and guidelines
Desirable
2
AVAILABILITY
or
Desirable
1 Core operating hours 8am to 6pm, Monday to Friday Essential
2 99% availability during core operating hours Essential
3 Any planned maintenance is expected to be carried out outside
these hours
Essential
4 Monthly reports provided on the amount of downtime/uptime Essential
5
USER ACCESS
or
Desirable
1
ACCESSIBILITY
or
Desirable
1 The product will adhere to World Wide Web Consortium (W3C)
accessibility standards and guidelines
Essential
2
USABILITY
or
Desirable
1 Desirable

Notes:
IT SERVICE CONTINUITY (DISASTER RECOVERY)
or
Desirable
1 A disaster recovery process will be in place. The system will be able
to be recovered and available within 48 hours of a disaster event.
Desirable
2
PERFORMANCE
or
Desirable
1 Response times for users will be 4 seconds maximum response to
all web pages.
Desirable
2
CAPACITY/VOLUME
or
Desirable
1
INTEROPERABILITY
or
Desirable
1
DATA
or
Desirable
1

Notes:
AUDIT
or
Desirable
1
REQUIREMENTS IMPOSED BY SPECIFIC LEGISLATION STRATEGIES
GENERAL
or
Desirable
1
PRIVACY
or
Desirable
1
CONSTRAINTS
Id Description
1 Developer resource limits.
2 The product will be a web application and as such the interface needs to be compliant
with standard web browsers including but not limited to Internet Explorer 6 & 7 and
Mozilla Firefox
3 Compliance with OWASP and W3C standards. This constraint is self-imposed. Refer to
sections 3.2.2 and 3.2.4.
4 Due to web standards and accessibility the interface is constrained to HTML, CSS and
JavaScript
5

Notes:
ASSUMPTIONS
Id Description
1
RISKS
Id Description
1

Notes:
SUPPORTING MATERIAL – EXAMPLE TECHNICAL
ARCHITECTURE

Notes:
CONCEPTUAL SYSTEM DESIGN SECTION
Conceptual System Checklist Responses - Select all that apply
Project Type  New System
 Upgrade System
 Other (specify):
Development Approach  Commercial Off The Shelf (COTS )
 Government Off The Shelf (GOTS )
 Custom
Delivery of Functionality  Modular (functionality delivered over time)
 Monolithic (functionality delivered all at once)
System Interactions  Business to Business (B2B)
 Business to Customer (B2C)
Electronic Commerce  Yes
 No
Pilot Prior to Implementation  Yes
 No
Security - Regulatory or Privacy
Requirements
W3C Accessibility Compliance  Yes
 No
Estimated Total Number of
Customers
Total:
By Audience:
Customer: ______ Employee: _____ Business:_____
Other:______
Estimated Total Number of
Concurrent Customers
Total:
By Audience:
Customer: ______ Employee: _____ Business:_____
Other:______
Average Transaction Response
Time Requirements
Platform: Windows XP Pro, PIV 1.2Ghz, 512MB RAM
Bandwidth: DSL/Cable (1Mb, 50% utilized)
Average File Size: ____
Platform: Windows XP Pro, PIV 1.2Ghz, 512MB RAM
Bandwidth: LAN (10Mb, 50% utilized)
Average File Size: 30Kb
Production Hours of Operation
Production Availability Uptime => Downtime/year (i.e. unplanned)

Notes:
Expectations 99% (2 Nines) => 003d 15h 36m 00s
Application Backup Requirements Full Backup:
__ Real Time __ Daily __ Weekly
Incremental Backup:
__ Hourly __ Daily __ Weekly
Application Recovery Requirements Recovery Time Objective:
Disaster Recovery Requirements Hot Site: __ hour(s)
Warm Site: __ days(s)
Cold Site: __ days(s)
Hosting Location
Architectural Approach  SOA
 3/N Tier
Processing Type  OLTP
 OLAP
Development Platform  J2EE
 .NET
 PHP
Architectural Framework(s)
Architectural Pattern(s)  MVC
 Factory
 Controller
 Data Access Object
Software Testing Test Driven Design Methodology (TDD) - basic tests are
developed before the software is written.
Tests include;
 Functional
 Performance
 Accessibility
 User Acceptance
Security Technologies  Identity and Access Management
 SSL/TLS
 Data Encryption
 Cookie Encryption
 __ DES __ 3DES __ AES __ Other (specify):

Notes:
CONCEPTUAL SYSTEM DESIGN DIAGRAM
<Insert Physical Architecture Diagram>
<Descript Physical Architecture Diagram>
DETAIL SYSTEM DESIGN CHECKLIST
Detail System Checklist Responses – Select all that apply
Client Operating Systems  Apple
 Microsoft
 Linux
 Unix
 Palm
 Microsoft PocketPC
Client Platforms  Desktop/Laptop
 Tablet
 PDA
 Smart Phone
Client Footprint by Platform Specify size of footprint in KB or MB:
Desktop/Laptop:
Tablet:
PDA:
Smart Phone:
Other (specify):
Client Connection Speed Specify speed in kbps or mbps:
Minimum:
Recommended:
Client Richness  Browser Based
 Rich Client
 Rich Internet (AJAX)
Browsers and Versions Supported  Internet Explorer:
 Mozilla Firefox:
 Safari:
 Opera:
Presentation - Client Side
Languages
 HTML
 DHTML

Notes:
 XML
 XHTML
 VB.NET
 C#
 ActiveX Controls
 Java Applets
 Java
 JavaScript
 VBScript
 C++
Application State  Cookies (Non-Persistent Cookies, Persistent
Cookies)
 Session Ids
 State Stored in Hidden Fields
Virtualization  Server
 Storage
Web Server Location  Public Facing
 Internal Facing
Web Server Operating System  Windows
 Linux
 Unix
 Specify Version:
Web Server Software  Apache
 Microsoft
 Sun
 Oracle
 Specify Edition and Version:
Web Server - High Availability Load Balanced: __ Yes __ No
Processor Architecture: __ 64 Bit __ 32 Bit
Processor Cores: __ Double __ Single
Other (specify):
Web Server - Specifications Rollout Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type:
_________
CPU Speed: _____ Amount of RAM: ____
Maximum Configuration:

Notes:
__________
Presentation – Server Side
Languages
 ASP.NET
 VB.NET
 C#
 PHP
 JSP
 Servlets
 Java
 Server Side Includes (SSI)
 C++
Application Server Operating
System
 Windows
 Linux
 Unix
Application Server Software  Microsoft
 IBM
 Sun
 Oracle
 BEA
 Specify Edition and Version:
Application Server – High
Availability
Processor Architecture: __ 64 Bit __ 32 Bit
RAID Supported: __ Yes __ No
SAN Supported: __ Yes __ No
Mirroring Supported: __ Yes __ No
Clustering Supported: __ Yes __ No
Grid/On Demand Supported: __ Yes __ No
Other (specify):
Application Server - Specifications Rollout Configuration:
_________
__________

Notes:
Business Rule – Application
Languages
 VB.NET
 C#
 PHP
 Java (J2SE)
 Java/EJB (J2EE)
 C++
Database Server Operating System  Windows
 Linux
 Unix
Database Server Software  Microsoft
 IBM
 Oracle
 PostgreSQL
 MySQL
Database Server – High Availability Processor Architecture: __ 64 Bit __ 32 Bit
RAID Supported: __ Yes __ No
SAN Supported: __ Yes __ No
Mirroring Supported: __ Yes __ No
Clustering Supported: __ Yes __ No
Grid/On Demand Supported: __ Yes __ No
Other (specify):
Database Server - Specifications Rollout Configuration:
_________
__________
Data Access – Connectivity
Methods
 ADO.NET
 ODBC
 OLE/DB
 JDBC

Notes:
 JDO
 DB2 Connect
SQL Languages  T/SQL
 PL/SQL
Stored Procedures Utilization No
Yes
__ Data Access only
__ Business Rules and Data Access
SYSTEM DESIGN DESCRIPTION
<Insert High Detail Physical Architecture Diagram>
<Describe High Detail Physical Architecture Diagram>
BUSINESS CONTINUITY
<Describe Business Continuity / Disaster Recovery Procedures In Place>
EXPECTED ISSUES
<Describe Issues Or Link To Issues Register>

Notes:
SUPPORTING MATERIAL – EXAMPLE DESIGN PAGE

Notes:
Story: ______________________________________________________
Estimate Priority
Value Risk
Purpose Test Cases
Use Cases Notes

Notes:
SUPPORTING MATERIAL – EXAMPLE RELEASE APPROVAL

Notes:
RELEASE APPROVAL
Release Name: ___________________________________
Version: __________________________________________
Date: _____________________________________________
COMPLIANCE OUTCOME
Requirement Pass/Fail Notes
DEFECT TESTING OUTCOME
Name Pass/Fail Notes

Notes:
PERFORMANCE TESTING OUTCOME
Name Pass/Fail Tests
(All results are the average of 10 loads at SSC
level)
Single User
1000 Users
Single User
1000 Users
Single User
1000 Users
Single User
1000 Users
Single User
1000 Users
Single User
1000 Users
Single User
1000 Users
Single User
1000 Users
ISSUES TO CARRY OVER TO THE NEXT RELEASE

Notes:
SIGN OFF
Technical Program Final
<Name> <Name> <Name>

Agile Methods - course notes

More Related Content

What's hot (20)

Similar to Agile Methods - course notes (20)

More from Evan Leybourn (16)

Agile Methods - course notes