AMITY UNIVERSITY 
AGILE SOFTWARE DEVELOPMENT 
NOTES- MODULE 1 - MODULE 6 
SEMESTER 7, session 2019-2020 
Prepared by Chhaya Khattri 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
MODULE 1 
What is Agile? 
 
Agile  is  the  ability  to  create  and  respond  to  change.  It  is  a  way  of  dealing  with,  and  ultimately 
succeeding in, an uncertain and turbulent environment. 
The  authors  of  the  Agile  Manifesto  chose  “Agile”  as  the  label  for  this  whole  idea  because  that 
word  represented  the  adaptiveness  and  response  to  change  which  was  so  important  to  their 
approach. 
 
It’s  really  about  thinking  through  how  you  can  understand  what’s  going  on in the environment 
that  you’re  in  today,  identify  what  uncertainty  you’re  facing,  and  figure  out  how you can adapt 
to that as you go along. 
 
What is Agile Software Development? 
 
Agile  software development is more than frameworks such as Scrum, Extreme Programming or 
Feature-Driven Development (FDD). 
 
Agile  software  development  is  more  than  practices  such  as  pair  programming,  test-driven 
development, stand-ups, planning sessions and sprints. 
 
Agile  software  development  is  an  umbrella  term  for a set of frameworks and practices based on 
the  values  and  principles  expressed in the Manifesto for Agile Software Development and the 12 
Principles  behind  it.  When  you  approach  software  development  in  a  particular  manner,  it’s 
generally  good  to  live  by  these  values  and  principles  and  use  them  to  help  figure  out  the  right 
things to do given your particular context. 
 
One  thing  that  separates  Agile  from  other  approaches  to  software  development  is  the  focus  on 
the  people  doing  the  work  and  how  they  work  together.  Solutions evolve through collaboration 
between  self-organizing  cross-functional  teams  utilizing  the  appropriate  practices  for  their 
context. 
 
There’s  a  big  focus  in  the  Agile  software  development  community  on  collaboration  and  the 
self-organizing team. 
 
That  doesn’t  mean  that there aren’t managers. It means that teams have the ability to figure out 
how they’re going to approach things on their own. 
 
It  means  that  those  teams  are  cross-functional.  Those  teams  don’t  have  to  have  specific  roles 
involved  so  much  as  that  when  you  get  the  team  together,  you  make  sure  that  you  have  all  the 
right skill sets on the team. 
 
There  still  is  a  place  for  managers.  Managers  make  sure  team  members  have,  or  obtain,  the 
right  skill  sets.  Managers  provide  the  environment  that  allows  the  team  to  be  successful. 
Managers  mostly  step  back  and let their team figure out how they are going to deliver products, 
but they step in when the teams try but are unable to resolve issues. 
 
When  most  teams  and  organizations  start  doing Agile software development, they focus on the 
practices  that  help  with  collaboration  and  organizing  the  work,  which  is  great.  However, 
another  key  set  of  practices  that  are  not  as  frequently  followed  but  should  be  are  specific 
technical  practices  that  directly  deal  with developing software in a way that help your team deal 
with uncertainty. 
 
The Agile Manifesto 
 
We  are  uncovering  better  ways  of  developing  software  by  doing  it  and  helping  others  do  it. 
Through this work we have come to value: 
 
● Individuals and interactions over processes and tools 
 
● Working software over comprehensive documentation 
 
● Customer collaboration over contract negotiation 
 
● Responding to change over following a plan 
 
That is, while there is value in the items on the right, we value the items on the left more. 
 
The following 12 Principles are based on the Agile Manifesto. 
 
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 timescale. 
 
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 maximizing the amount of work not done–is essential. 
 
11 The best architectures, requirements, and designs emerge from self-organizing teams. 
 
12  At  regular  intervals,  the  team  reflects  on  how  to  become  more  effective,  then  tunes  and 
adjusts its behavior accordingly. 
 
 
The  Agile  methodologies  outlined  below  share  much  of  the  same  overarching  philosophy,  as 
well  as  many  of  the  same  characteristics  and  practices.  From  an  implementation  standpoint, 
however, each has its own unique mix of practices, terminology, and tactics. 
 
The most widely-used Agile methodologies include: 
● Agile Scrum Methodology 
● Lean Software Development 
● Kanban 
● Extreme Programming (XP) 
● Crystal 
● Dynamic Systems Development Method (DSDM) 
● Feature Driven Development (FDD) 
 
Agile Scrum Methodology 
Scrum  is  a  lightweight  Agile  project  management  framework  that  can  be  used  to  manage 
iterative  and  incremental projects of all types. It has gained increasing popularity over the years 
due  to  its  simplicity,  proven  productivity,  and  ability  to  incorporate  various  overarching 
practices promoted by other Agile models. 
 
In  Scrum,  the  Product  Owner  works  closely  with  their  team  to  identify  and  prioritize  system 
functionality  by  creating  a  Product  Backlog.  The  Product Backlog consists of whatever needs to 
be  done  to  successfully  deliver  a  working  software  system,  including  features,  bug  fixes, 
non-functional  requirements,  etc.  Once  priorities  have  been  established,  cross-functional 
teams  will  estimate  and  sign-up  to  deliver  “potentially  shippable  increments”  of  software 
during  successive  Sprints,  typically  lasting  30  days.  Once  a  Sprint’s  Product  Backlog  is 
committed,  no  additional  functionality  can  be  added  to  the  Sprint  except  by  the  team.  Once  a 
Sprint  has  been  delivered,  the  Product  Backlog  is  analyzed  and  reprioritized  if  necessary,  and 
the next set of deliverables is selected for the next Sprint. 
 
Lean Software Development 
Lean  Software  Development  is  an  iterative  Agile  methodology  that  focuses  the  team  on 
delivering  value  to  the  customer  through  effective  value  stream mapping. It is a highly flexible, 
evolving methodology without rigid guidelines, rules, or methods. 
 
 
The main principles of the Lean methodology include: 
● Eliminating Waste 
● Amplifying Learning 
● Deciding as Late as Possible 
● Delivering as Fast as Possible 
● Empowering the Team 
● Building Integrity In 
● Seeing the Whole 
 
Lean  development  eliminates  waste  by  asking  users  to select only the truly valuable features for 
a  system,  prioritize  those  features,  and  then  work  to  deliver  them  in  small  batches. It relies on 
rapid  and  reliable  feedback  between  programmers  and  customers,  emphasizing  the  speed  and 
efficiency  of  development  workflows.  Lean  uses  the  idea  of  a  work  product  being  “pulled”  via 
customer  request.  It  gives  decision-making  authority  to  individuals  and  small teams since this 
has  been  proven  to  be  a  faster  and  more  efficient  method  than  a  hierarchical  flow  of  control. 
Lean  also  concentrates  on  the  efficient  use  of  team  resources,  trying  to  ensure that everyone is 
as  productive  as  possible  for  the  maximum  amount  of  time.  It  strongly  recommends  that 
automated unit tests be written at the same time the code is written. 
 
Kanban 
Kanban  is  a  highly  visual  workflow  management  method that is popular among Lean teams. In 
fact,  83%  of  teams  practicing  Lean  use  Kanban  to  visualize  and  actively  manage the creation of 
products  with  an  emphasis  on  continuous  delivery,  while  not  adding  more  stress  to  the 
software  development  life  cycle.  Like  Scrum,  Kanban  is  a  process  designed  to  help teams work 
together more effectively. 
 
Kanban is based on 3 basic principles: 
● Visualize  what  you’ll  do  today  (workflow  automation):  ​Seeing  all  the  items  within  the 
context of each other can be very informative 
● Limit  the  amount  of  work  in  progress  (WIP):  This  helps  balance  the  flow-based 
approach so teams don‘t start and commit to too much work at once 
● Enhance  flow:  When  something  is  finished,  the  next  highest  priority  item  from  the 
backlog is pulled into play 
 
Kanban  promotes  continuous  collaboration  and  encourages  active,  ongoing  learning  and 
improvement by defining the best possible team workflow. 
 
Extreme Programming (XP) 
Extreme  Programming  (XP),  originally  described by Kent Beck, has emerged as one of the most 
popular  and  controversial  Agile  models.  XP  is  a  disciplined  approach  for  high-quality  agile 
software  development,  focused  on  speed  and  continuous  delivery.  It  is  intended  to  improve 
software  quality  and  responsiveness  in  the  face  of  changing  customer  requirements.  It 
promotes  high  customer  involvement,  rapid  feedback  loops,  continuous  testing,  continuous 
planning,  and  close  teamwork  to  deliver  working  software  at  very  frequent  intervals,  typically 
every 1-3 weeks. 
 
The  methodology  takes  its  name  from  the  idea  that  the  beneficial  elements  of  traditional 
software  engineering  practices  are  taken  to  “extreme”  levels.  As  an  example,  code  reviews  are 
considered  a  beneficial  practice.  Taken  to  the  extreme,  code  can  be  reviewed  continuously 
through the practice of pair programming. 
 
The  original  XP  method  is  based  on  four  simple  values:  simplicity,  communication,  feedback, 
and courage. 
 
It also has twelve supporting practices: 
● Planning Game 
● Small Releases 
● Customer Acceptance Tests 
● Simple Design 
● Pair Programming 
● Test-Driven Development 
● Refactoring 
● Continuous Integration 
● Collective Code Ownership 
● Coding Standards 
● Metaphor 
● Sustainable Pace 
 
Don Wells has depicted the XP process in this popular diagram: 
 

 
 
 
 
In  XP,  the  customer  works  closely  with  the  development  team  to  define  and  prioritize  user 
stories.  The  development team estimates, plans, and delivers the highest priority user stories in 
the  form  of  working,  tested  software  on  an  iteration-by-iteration  basis.  In  order  to  maximize 
productivity,  the  practices  provide  a  supportive,  lightweight  framework  to  guide  a  team  and 
ensure high-quality enterprise software. 
 
Crystal 
 
The  Crystal  methodology  is  one  of  the  most  lightweight,  adaptable  approaches  to  software 
development.  Crystal  is  actually  comprised  of  a  family  of  Agile  process  models,  including 
Crystal  Clear, Crystal Yellow, Crystal Orange and others. Each has unique characteristics driven 
by  several  factors,  such  as  team  size,  system  criticality,  and  project  priorities.  This  Crystal 
family  addresses  the  realization  that  each  project  may  require  a  slightly  tailored set of policies, 
practices, and processes in order to meet the product ‘s unique characteristics. 
 
Introduced  by  Alistair  Cockburn,  Crystal  focuses  primarily  on  people  and  the  interaction 
among  them  while  they  work  on  agile  software  development  project.  There  is  also  a  focus  on 
business-criticality and business-priority of the system under development. 
 
What is agile project management? 
 
Agile  project  management  is  a  modern,  flexible  approach to project management. It allows you 
to  break  large  projects  down  into  more  manageable  tasks,  which  are  tackled in short iterations 
or sprints. This enables your team to adapt to change quickly and deliver work fast. 
Unlike  traditional  development  methods,  Crystal  doesn’t  try  to  fix  the  tools  and  techniques  of 
development  but  keeps  people  and  processes  at  the  core  of  the  process.  However,  it is not only 
the  people or the processes that are important, rather the interaction between them that is most 
important. 
 
Several  key  tenets  of  Crystal  include  teamwork,  communication,  and  simplicity,  as  well  as 
reflection  to  frequently  adjust  and  improve  the  process.  Like  other  Agile  frameworks,  Crystal 
promotes early, frequent delivery of working software, high user involvement, adaptability, and 
the removal of bureaucracy or distractions. 
 
Dynamic Systems Development Method (DSDM) 
 
The  Dynamic  Systems  Development  Method  (DSDM)  is  an  Agile  approach  that  grew  out  of the 
need  to  provide  a  common  industry  framework  for  rapid  software  delivery.  Since  1994,  the 
DSDM  methodology  has  evolved  to  provide  a  comprehensive  foundation  for  planning, 
managing, executing, and scaling Agile process and iterative software development projects. 
 
DSDM  is  based  on  eight  key  principles  that  direct  the  team  and  create  a  mindset  to  deliver  on 
time  and  within  budget.  These  agile  principles  primarily  revolve  around  business  needs/value, 
active  user  involvement,  empowered  teams,  frequent  delivery,  integrated  testing,  and 
stakeholder  collaboration.  DSDM  specifically  calls  out  “fitness  for  business  purpose”  as  the 
primary  criteria  for  delivery  and  acceptance  of  a  system,  focusing  on  the  useful  80%  of  the 
system that can be deployed in 20% of the time. 
 
Compromising  any  of  the  following  principles  undermines  the  philosophy  of  DSDM  and 
introduces risk to the successful outcome of the project. 
 
DSDM’s Eight Key Principles:  
● Focus on the business need 
● Deliver on time 
● Collaborate 
● Never compromise quality 
● Build incrementally from firm foundations 
● Develop iteratively 
● Communicate continuously and clearly 
● Demonstrate control 
 
Business  Requirements  are  baselined  at  a  high  level  early  on in the project. Rework is built into 
the  process,  and  all  development changes must be reversible. System requirements are planned 
and  delivered  in  short,  fixed-length  time-boxes  –  also  known  as  sprints  or  iterations  –  and 
prioritized using MoSCoW Rules. 
 
MoSCoW Rules: 
M – Must have requirements 
S – Should have if at all possible 
C – Could have but not critical 
W – Won‘t have this time, but potentially later 
 
All  critical  work  must  be  completed  in  a  DSDM  project’s  defined  time-box.  It is also important 
that  not  every  requirement  in  a  project  or  time-box  is  considered  critical.  Within  each 
time-box,  less  critical  items  are  also  included  so  that  they  can  be  removed  to  keep  from 
impacting higher priority requirements on the schedule. 
 
Feature Driven Development (FDD) 
 
Feature  Driven  Development  is  a  model-driven,  short-iteration  process  that  was  built  around 
software  engineering  best  practices  such  as  domain  object  modeling,  developing  by  feature, 
and code ownership. The blending of these practices that resulted in a cohesive whole is the best 
characteristic of FDD. 
 
Feature Driven Development consists of five basic activities: 
● Development of an overall model 
● Building a feature list 
● Planning by feature 
● Designing by feature 
 ● Building by feature 
FDD  begins  by  establishing  an  overall  model  shape,  which  will  result  in  a  feature  list.  It  then 
continues  with  a  series  of  two-week  “plan  by  feature,  design  by  feature,  build  by  feature” 
iterations.  The  features  are  small,  “useful in the eyes of the client” results. If they will take more 
than two weeks to build, then they will have to be broken down into smaller features. 
 
FDD’s  main  purpose  is  to  deliver  tangible,  working  software  in  a  timely  manner,  repeatedly. 
The  advantage  of  using  FDD  is  that  it  is  scalable  even  to  large  teams  due  to  the concept of ‘just 
enough  design  initially’  (JEDI). Because of its feature-centric process, FDD is a great solution to 
maintain control for incremental and inherently complex Agile project management. 
 
The team members 
 
Each  agile  project  methodology  has  its  own  unique  list  of  team  members,  and  while  the  titles 
may change, there are a few universal characteristics that agile team members should have: 
 
1. T-shaped.  A  valuable  team  member  has  a  wide  breadth  of  basic  knowledge  about  their 
subject but also deep knowledge, experience, and ability in one (or more) specific areas. 
2. Cross-functional.  Cross-functional  team  members  have  skills  outside  their  traditional 
areas.  They  might  know  some  basic  graphic  design  principles  and  data  analysis or even 
some HTML/CSS. 
3. Adaptable.  ​If  they  have  a  diverse  skill  set,  they  know  how  to  use  it.  No  matter  the 
environment, their output remains consistent. 
4. Curious.  ​Part  of  optimizing  and  becoming  more  efficient  is  asking  the  right  questions 
and challenge the way things have always been when it’s appropriate. 
5. Entrepreneurial.  An  agile  team  member  is  one  that  doesn’t  wait  to  be  told  what  to  do. 
They’re ready to fill in and develop campaigns where they see a need. 
6. Team-oriented.  ​Team  players  prioritize  the  success  of the team over their own personal 
glory. If everyone is delivering on time and syncing well together, they see that as a win. 
7. Committed  to  excellence.  One  of  the  key  benefits  of  agile  projects  is  delivering  quality 
work,  faster.  Team  members  who  are  committed  to  excellence  don’t  settle  for  average. 
They’re  not  hung  up  on  perfection,  but  they’re  dedicated  to  always  producing their best 
work. 
 
What are the 6 steps in the agile methodology?  
The  goal  of  agile  is  to  produce  shorter  development  cycles  and  more  frequent  product  releases 
than  traditional  waterfall  project  management.  This  shorter  time  frame  enables  project  teams 
to react to changes in the client’s needs more effectively. 
 
As  we  said  before,  you  can  use  a  few  different  agile  project  management  frameworks—Scrum 
and  Kanban  are  two  of  the  most  common.  But  each  agile  project  methodology  will  follow  the 
same basic process, which includes: 
 
 
 
1. Project planning 
Like  with  any  project,  before  beginning  your  team should understand the end goal, the value to 
the organization or client, and how it will be achieved. 
 
You  can  develop  a  project  scope  here,  but  remember  that  the  purpose  of  using  agile  project 
management  is  to  be  able  to  address  changes  and  additions  to  the  project  easily, so the project 
scope shouldn’t be seen as unchangeable. 
 
2. Product roadmap creation 
A  roadmap  is  a  breakdown  of  the  features  that  will  make  up  the  final  product.  This  is a crucial 
component  of  the  planning  stage, because your team will build these individual features during 
each sprint. 
 
At  this  point,  you  will  also  develop  a  product  backlog,  which  is  a  list  of  all  the  features  and 
deliverables  that  will  make  up  the  final  product.  When  you plan sprints later on, your team will 
pull tasks from this backlog. 
 
3. Release planning 
In  traditional  waterfall  project management, there is one implementation date that comes after 
an  entire  project  has  been  developed.  When  using an agile project methodology, however, your 
project  uses  shorter  development cycles (called sprints) with features released at the end of each 
cycle. 
 
Before  kicking  off  the  project,  you’ll  make  a  high-level  plan  for  feature  releases  and  at  the 
beginning of each sprint, you’ll revisit and reassess the release plan for that feature. 
 
4. Sprint planning 
Before  each  sprint  begins,  the  stakeholders  need  to  plan  what  will  be  accomplished  by  each 
person  during  that  sprint,  how  it  will  be  achieved,  and  assess  the  task  load.  It’s  important  to 
share  the  load  evenly  among  team  members so they can accomplish their assigned tasks during 
the sprint. 
 
You’ll  also  need  to  visually  document  your  workflow  for  team  transparency,  shared 
understanding within the team, and identifying and removing bottlenecks. 
 
5. Daily meetings 
To  help  your  team  accomplish  their  tasks  during  each  sprint  and  assess  whether  any  changes 
need  to  be  made,  hold  short  daily  meetings.  During  these  meetings,  each  team  member  will 
briefly  talk  about  what  they  accomplished  the  day  before  and  what they will be working on that 
day. 
 
These  daily  meetings  should  be  only  15  minutes  long.  They  aren’t  meant  to  be  extended 
problem-solving  sessions  or  a  chance  to  talk  about  general  news  items.  Some  teams  will  even 
hold these meetings standing up to keep it brief. 
 
6. Sprint review and retrospective  
After  the  end  of  each  sprint,  your  team  will  hold  two  meetings:  first,  you  will  hold  a  sprint 
review  with  the  project  stakeholders  to  show  them  the  finished  product.  This  is  an  important 
part of keeping open communication with stakeholders. 
 
An  in-person  or  video  conference  meeting  allows  both  groups  to  build  a  relationship  and 
discuss product issues that arise. 
 
Second,  you  will  have  a  sprint  retrospective  meeting  with  your  stakeholders  to  discuss  what 
went  well  during  the  sprint,  what  could  have  been  better,  whether  the  task  load  was  too  heavy 
or too light for each member, and what was accomplished during the sprint. 
 
If  your  team  is  new  to  agile  project  management, don’t skip this essential meeting. It helps you 
gauge  how  much  your  team  can  tackle  during  each  sprint  and  the  most  efficient  sprint  length 
for future projects. 
 
These  are  the most basic and important parts of an agile project methodology. As you transition 
your  team  to  an  agile  methodology,  these  processes,  roles,  and  principles  will  help  you  change 
your  mindset  and  begin  working  together  to  be  more  flexible  and  adapt  to  changes  as  they 
come. 
 
Early  adopters  of  agile  development  were  small,  self-contained  teams  working  on  small, 
self-contained  projects.  They  proved  the  agile  model  can  work,  to  the  joy  and  betterment  of 
software  makers  around the world. More recently, larger organizations are scaling agile beyond 
single teams or projects, and seeking ways to apply it to whole programs.  
 
 
Waterfall versus agile 
 
Let's start with the basics–like what makes agile different.  
 
Traditional project management styles, like waterfall, build in phases. Below is an illustration of 
a  standard  waterfall  project.  This  style  of  product  development  folds  everything  into  a  single, 
"big  bang",  high-risk  release.  Once  a  project  passes  one  phase,  it's  painful  to  revisit  it  because 
teams are always pressing forward to the next stage. 
 
Traditional  project  management  styles  often  create  "critical  paths",  where  the  project  can't 
move  forward  until  a  blocking  issue  is  resolved.  To  add  insult  to  injury, the end customer can't 
interact  with  the  product  until  it's  fully  complete.  Thus,  important  issues  in  the  product's 
design, and code, go undiscovered until release. 
 
Let's  contrast  that  with  an  agile project management style, which takes an iterative approach to 
development  with  regular  feedback  intervals.  These  iterations  allow for the team to be diverted 
to (and productive in) another area of the project while a blocking issue is resolved. 
 
Besides  removing  critical  paths,  iterations  let  you  interact  with  the  product  during 
development. 
 
This,  in  turn,  gives  the  team  constant  opportunities  to  build, deliver, learn, and adjust. Market 
changes  don't  catch  you  flat-footed,  and  teams  are  prepared  to  adapt  quickly  to  new 
requirements. 
 
An  even  greater  benefit  is  shared  skill  sets  among  the  software  team.  The  team's  overlapping 
skill sets add flexibility to work in all parts of the team's code base. This way, work and time isn't 
wasted  if the project direction changes. (For more on that, see our article on building great agile 
teams.) 
 
How to build a great agile program 
When  a  program  transitions  from  traditional  project  management  to  agile,  the  team  and  the 
stakeholders must embrace two important concepts: 
 
The  product  owner's  focus  is  to  optimize  the  value  of  the  development  team's  output.  The 
development team relies on the product owner prioritizing the most important work first. 
The  development  team  can  only  accept  work as it has capacity for it. The product owner doesn't 
push  work  to  the  team  or  commit  them  to  arbitrary  deadlines.  The  development  team  pulls 
work from the program's backlog as it can accept new work. 
Let's  explore  the  mechanisms  agile  programs  use  to  organize,  run,  and  structure  work  in  an 
iterative way. 
 
Roadmaps 
A  roadmap  outlines  how  a  product  or  solution  develops  over  time.  Roadmaps  are  composed of 
initiatives,  which  are  large  areas  of  functionality,  and  include  timelines  that  communicate 
when  a  feature  will  be  available.  As  the  program  develops,  it's  accepted  that  the  roadmap  will 
change–sometimes  subtly,  sometimes  broadly.  The  goal  is  to  keep  the  roadmap  focused  on 
current market conditions and long-term goals.  
 
Requirements 
Each  initiative  in  the  roadmap  breaks  down  into  a  set  of  requirements.  Agile requirements are 
lightweight  descriptions  of  required  functionality,  rather  than  the  100-page  documents 
associated  with  traditional  projects.  They  evolve  over  time  and  capitalize  on  the  team's  shared 
understanding  of  the  customer  and  the  desired  product.  Agile  requirements remain lean while 
everyone  on  the  team  develops  a  shared  understanding  via  ongoing  conversation  and 
collaboration.  Only  when  implementation  is  about  to  begin  are  they  are  fleshed  out  with  full 
details.  
 
 
Backlog 
The  backlog  sets  the  priorities  for  the  agile  program.  The  team  includes  all  work  items  in  the 
backlog:  new  features,  bugs,  enhancements,  technical  or  architectural  tasks,  etc.  The  product 
owner  prioritizes  the  work  on  the  backlog  for  the  engineering  team.  The  development  team 
then uses the prioritized backlog as its single source of truth for what work needs to be done.  
 
Agile delivery vehicles 
Agile  can  be  implemented  using  various  frameworks  (like  scrum  and  kanban)  to  deliver 
software.  Scrum  teams  use  sprints  to  guide  development,  and  kanban  teams  often  work 
without  fixed  work  intervals.  Both  frameworks,  however,  use  large  delivery  vehicles  like  epics 
and versions to structure development for a synchronized release cadence out to production. 
 
Agile metrics 
Agile  teams  thrive  on  metrics.  Work  in  progress  (WIP)  limits  keep  the  team,  and  the business, 
focused  on  delivering  the  highest  priority  work.  Graphs  like  burndown  and  control charts help 
the  team  predict  their  delivery  cadence,  and  continuous  flow  diagrams  help  identify 
bottlenecks.  These  metrics  and  artifacts  keep  everyone  focused  on  the  big  goals  and  boost 
confidence in the team's ability to deliver future work.  
 
Agile runs on trust 
An  agile  program  cannot  function  without  a  high  level  of  trust  amongst  team  members.  It 
requires  candor  to  have  difficult  conversations  regarding  what's  right  for  the  program  and the 
product.  Because  conversations  happen  at  regular  intervals,  ideas  and  concerns  are  regularly 
expressed.  That  means  team  members  also  have  to  be  confident  in  each  other's  ability  (and 
willingness) to execute on the decisions made during those conversations. 
 
In  summary,  agile  development  is  a  structured  and  iterative  approach  to  making  software.  It 
gives  you  the  ability  to  respond  to  change  without  going  off  the  rails.  And  that's good news for 
any program.  
 
Test Driven Development 
 
Definition 
“Test-driven  development”  refers  to  a  style  of  programming in which three activities are tightly 
interwoven:  coding,  testing  (in  the  form  of  writing  unit  tests)  and  design  (in  the  form  of 
refactoring). 
 
It can be succinctly described by the following set of rules: 
 
● write a “single” unit test describing an aspect of the program 
● run the test, which should fail because the program lacks that feature 
● write “just enough” code, the simplest possible, to make the test pass 
● “refactor” the code until it conforms to the simplicity criteria 
● repeat, “accumulating” unit tests over time 
 
 
Expected Benefits 
 ● many  teams  report  significant  reductions  in  defect  rates,  at  the  cost  of  a  moderate 
increase in initial development effort 
● the  same  teams  tend  to  report  that  these  overheads  are  more  than  offset by a reduction 
in effort in projects’ final phases 
● although  empirical  research  has  so  far  failed  to  confirm  this,  veteran  practitioners 
report  that  TDD  leads  to  improved  design  qualities  in  the  code,  and  more  generally  a 
higher  degree  of  “internal”  or  technical  quality,  for  instance  improving  the  metrics  of 
cohesion and coupling 
 
Common Pitfalls 
 
Typical individual mistakes include: 
● forgetting to run tests frequently 
● writing too many tests at once 
● writing tests that are too large or coarse-grained 
● writing overly trivial tests, for instance omitting assertions 
● writing tests for trivial code, for instance accessors 
 
Typical team pitfalls include: 
● partial adoption – only a few developers on the team use TDD 
● poor  maintenance  of  the  test  suite  –  most  commonly  leading  to  a  test  suite  with  a 
prohibitively long running time 
● abandoned  test  suite  (i.e.  seldom  or  never  run)  –  sometimes  as  a  result  of  poor 
maintenance, sometimes as a result of team turnover 
 
Signs of Use 
● “code  coverage”  is  a  common  approach  to  evidencing  the  use  of  TDD;  while  high 
coverage  does  not  guarantee  appropriate  use  of  TDD,  coverage  below  80%  is  likely  to 
indicate deficiencies in a team’s mastery of TDD 
● version  control  logs  should  show  that  test  code  is  checked  in  each  time  product  code  is 
checked in, in roughly comparable amounts 
 
User Stories 
 
Definition 
In  consultation  with  the  customer  or  product  owner,  the  team  divides  up  the  work  to  be  done 
into functional increments called “user stories.” 
 
Each  user story is expected to yield, once implemented, a contribution to the value of the overall 
product,  irrespective  of  the  order  of  implementation;  these  and  other  assumptions  as  to  the 
nature of user stories are captured by the INVEST formula. 
 
To  make  these  assumptions  tangible,  user stories are reified into a physical form: an index card 
or  sticky  note,  on  which  a  brief  descriptive  sentence  is  written  to  serve  as  a  reminder  of  its 
value.  This  emphasizes  the  “atomic”  nature  of  user  stories  and  encourages  direct  physical 
manipulation:  for  instance,  decisions  about  scheduling  are  made  by  physically  moving  around 
these “story cards”. 
 
 
Common Pitfalls 
● a  classic  mistake  consists,  in  teams  where  the  Agile  approach  is  confined  to  the 
development  team  or  adopted  after  a  non-Agile  requirements  phase,  to  start  from  a 
requirements  document  in  narrative  format  and derive user stories directly based on its 
structure: for instance one story for each section of the document 
● as  the  3  C’s  model  emphasizes,  a  user story is not a document; the term encompasses all 
of  the  knowledge  required  to  transform  a  version  V of the product into version V’ which 
is more valuable with respect to a particular goal 
● the  level  of  detail  corresponding  to  a  user  story  is  not  constant,  it evolves over time as a 
function  of  the  “planning  horizon”;  for  instance  a  user  story  which  is  scheduled  for  the 
next  iteration should be better understood than one which will not be implemented until 
the next release 
● a  user story is not a Use Case; although it is often useful to compare and contrast the two 
notions, they are not equivalent and do not admit a one-to-one mapping 
● a  user  story  does  not  in  general  correspond  to  a  technical  or  user  interface  component: 
even  though  it  may  sometimes  be  a  useful  shortcut  to  talk  about  e.g.  “the  search dialog 
story”, screens, dialog boxes and buttons are not user stories 
 
Expected Benefits 
 
For  most  Agile  teams  user  stories  are  the  main  vehicle  of  incremental  software  delivery,  and 
offer the following benefits: 
● mitigating the risks of delayed feedback, all the more so 
● if the increments are small 
● if the software is released to production frequently 
● for  the  customer  or  product owner, the option to change their mind on the details or the 
schedule priority of any user story not yet implemented 
● for  developers,  being  given  clear  and  precise  acceptance  criteria,  and ongoing feedback 
as they complete work 
● promoting  a  clear  separation  of  responsibilities  between  defining  the  “what”  (province 
of  the  customer  or  product  owner)  and  the  “how”  (province  of  the  technical  team), 
leveraging the skills and creativity of each 
 
Potential Costs 
Incremental  development  in  general,  and  the  “nano-incremental”  strategy  embodied  in  user 
stories  in  particular,  has  significant  impacts  on  projects’ testing strategies, and in particular all 
but mandates significant test automation. 
 
Signs Of Use 
● the  team  uses  visual planning tools (release plan, story map, task board) and index cards 
or stickies on these displays reflect product features 
 ● the  labels  on  cards  that  stand  for  user  stories  contain  few  or  no  references  to  technical 
elements (“database”, “screen” or “dialog”) but generally refer to end users’ goals 
 
 
Simple design 
 
Definition 
A  team  adopting the “simple design” practice bases its software design strategy on the following 
principles: 
● design is an ongoing activity, which includes refactoring and heuristics such as YAGNI 
● design quality is evaluated based on the rules of code simplicity 
● all  design  elements  such  as  “design  patterns”,  plugin-based  architectures,  etc.  are  seen 
as having costs as well as benefits, and design costs must be justified; 
● design  decisions  should  be  deferred  until  the  “last  responsible  moment”, so as to collect 
as  much  information  as  possible  on  the  benefits  of  the  chosen  option  before  incurring 
its costs. 
● Also Known As 
● the  practice is often reduced to the acronym YAGNI, for “You Aren’t Gonna Need It”; this 
alludes  to  the  usual  counter-argument  when  a  programmer  tries  to  propose  a  costly 
design  element  based  on  its  future  benefits  only  (“We’re  going  to  need  this  Factory 
sooner or later, we might as well put it in now.” “No, you aren’t gonna need it.”) 
● another  common  term  is  “emergent  design”,  emphasizing  that  good  global  design  can 
result  from  consistently  paying  attention  to  the  local  qualities  of  code  structure  (by 
analogy  with  the  processes  studied  by  complexity  theorists  where  purely  local  rules 
reliably give rise to consistent global properties) 
 
Common Pitfalls 
● the first (and fatal) mistake would be to downplay, for instance while staffing a team, the 
importance  of  significant  design  skill  among  the  team, on the basis that “the design will 
emerge”; emergence is not magic and such skills are still crucial 
● “simple  design”  only  refers to the “software” design; it is misleading to invoke the simple 
design  practice  to  justify  decisions which have to do with a customer or product owner’s 
requirements, or usability considerations 
● the  practice  may  be  ill-advised  when  design  practices  are  unlikely  to  be  consistent,  for 
instance if the development group is large and geographically distributed 
 
Signs Of Use 
● the team maintains a “backlog” of design-specific tasks: 
● design flaws requiring an explicit remediation through refactoring 
● opportunities to simplify existing code 
● potential design decisions deferred until more information comes in 
● this  backlog  doesn’t  remain  stagnant,  or  a  mere  list  of  complaints  never  addressed;  the 
team  sets  aside  enough  of  its  productive  time  to  regularly  address  the  issues  (or  decide 
to live with them) 
 ● the  team  regularly  uses  one  or  more  of  the  ancillary  practices  which  offer  explicit 
opportunities to discuss design 
● any  impression  that  relatively  straightforward  functional  changes  require  inordinate 
amounts  of  effort  to  implement  is  a  “warning  sign”  that  the  practice  may  not  be 
effectively used 
Expected Benefits 
● mitigates the common risk of overdesign (“gold plating”) 
● has  been  claimed  to  “flatten  the  cost  of  change  curve”  –  i.e. to keep the software easy to 
change,  because  all  design  decisions  are  agnostic  to  which  particular  changes  are 
expected 
 
Pair programming 
 
Definition 
Pair  programming  consists  of  two  programmers  sharing  a  single  workstation  (one  screen, 
keyboard  and  mouse  among  the  pair).  The  programmer  at  the  keyboard  is  usually  called  the 
“driver”,  the  other,  also  actively  involved  in the programming task but focusing more on overall 
direction  is  the  “navigator”;  it  is  expected  that  the  programmers  swap  roles  every  few  minutes 
or so. 
 
Also Known As 
More  simply  “pairing”;  the  phrases  “paired  programming”  and  “programming in pairs” are also 
used, less frequently. 
 
Common Pitfalls 
● both  programmers  must  be actively engaging with the task throughout a paired session, 
otherwise no benefit can be expected 
● a  simplistic  but  often  raised  objection  is  that  pairing  “doubles  costs”;  that  is  a 
misconception  based  on  equating  programming  with  typing  –  however,  one  should  be 
aware that this is the worst-case outcome of poorly applied pairing 
● at  least  the  driver,  and  possibly  both  programmers,  are  expected  to  keep  up  a  running 
commentary;  pair  programming  is  also  “programming  out loud” – if the driver is silent, 
the navigator should intervene 
● pair  programming  cannot  be  fruitfully  forced  upon  people,  especially  if  relationship 
issues,  including  the  most  mundane  (such  as  personal  hygiene),  are  getting  in  the  way; 
solve these first! 
 
Signs Of Use 
 
● the  room’s  furniture  and  workstations  are  set  up  so  as  to  encourage  pairing  (in  teams 
new  or  hostile  to  pairing,  obvious  mistakes  are  tolerated,  such  as  desks  with  too  little 
room for two chairs) 
● the  room’s  noise  level  is  controlled:  the  muted  conversations  from  several  simultanous 
pairs  create  a  background  hum  but  do  not  rise  to  the  level  where  they  would  disturb 
anyone’s work 
 ● if,  upon  entering  the  room,  you  spot  any  programmer  wearing  an  audio  headset,  take 
that  as  a  “negative”  sign  –  not  only  is  pairing  probably  not practiced in the team but the 
conditions for successful adoptions are likely not met 
 
Expected Benefits 
 
● increased  code  quality:  “programming  out  loud”  leads  to  clearer  articulation  of  the 
complexities  and  hidden  details  in  coding  tasks,  reducing  the  risk  of  error  or  going 
down blind alleys 
● better  diffusion  of  knowledge  among  the  team,  in  particular  when  a  developer 
unfamiliar with a component is pairing with one who knows it much better 
● better  transfer  of  skills,  as  junior  developers  pick  up  micro-techniques  or  broader skills 
from more experienced team members 
● large reduction in coordination efforts, since there are N/2 pairs to coordinate instead of 
N individual developers 
● improved  resiliency  of  a  pair  to  interruptions,  compared  to  an  individual  developer: 
when  one  member  of  the  pair  must attend to an external prompt, the other can remains 
focused on the task and can assist in regaining focus afterwards 
 
Potential Costs 
 
While  empirical studies have yet to yield definite results on either benefits or costs, a commonly 
cited  best-case  estimate  of 15% overhead is claimed for systematic pairing, relative to individual 
work;  this  overhead,  it  is  claimed  (again  with  some  empirical  support,  though  not  entirely 
conclusive),  is  compensated  by  gains  in  code  quality  which  usually  entails  significant 
maintenance penalties down the road. 
 
Continuous Integration 
 
Definition 
Teams practicing continuous integration seek two objectives: 
 
● minimize the duration and effort required by each integration episode 
● be able to deliver a product version suitable for release at any moment 
 
In  practice,  this  dual  objective  requires  an  integration  procedure  which  is  reproducible  at  the 
very  least,  and  largely  automated.  This  is  achieved  through  version  control  tools, team policies 
and conventions, and tools specifically designed to help achieve continuous integration. 
 
Common Pitfalls 
As  suggested  above,  the  practice  of  continuous  integration  should  not  be  confused  with  the 
tools  that  assist  it  (CI  servers  such  as  Cruise  Control,  Hudson,  etc.).  Continuous  integration  is 
first  and  foremost  a  matter  of  attitude  rather  than  tools,  and  it  relies on more than one kind of 
tool: tools for testing, tools for automating build processes, and tools for version control. 
Continuous  integration  aims  to  lessen  the  pain  of  integration  by  increasing  its  frequency. 
Therefore,  “any”  effort  related  to  producing  intermediate  releases,  and  which  the  team 
experiences  as  particularly  burdensome,  is  a  candidate  for  inclusion  in  the  team’s  continuous 
integration process. (This is the reasoning that leads teams to continuous deployment.) 
 
Signs of Use 
For most teams, continuous integration in practice amounts to the following: 
 
● use of a version control tool (CVS, SVN, Git, etc.) 
● an automated build and product release process 
● instrumentation  of  the build process to trigger unit and acceptance tests “every time any 
change is published to version control” 
● in  the  event  of  even  a  single  test  failing,  alerting the team of a “broken build” so that the 
team can reach a stable, releasable baseline again soonest 
● optionally,  the  use  of  a  tool  such  as  a  continuous  integration  server,  which  automates 
the process of integration, testing and reporting of test results 
● Look  for  a  dedicated  display  in  a  prominent  spot of the team room: this can be a normal 
monitor,  an  LED  display  or  even  a  lava  lamp,  with  the  sole  purpose  of  reporting  on  the 
result of the most recent integration. 
 
Observe  also  how  the  team  responds  to  a  broken  build,  suggesting  that  a defect may have been 
detected.  If  the  team  is  aware  of  defects,  but  tolerates them or continues working on a product 
that  isn’t  in a releasable state, the term continuous integration no longer applies, irrespective of 
tooling! 
 
Most Popular Agile Testing Tools In 2019 
 
We  will  take  a  look  at  the  most  popular  Agile  Testing  Tools  which  are  used  in  our  day-to-day 
testing activities: 
 
Let's start. 
 
#1) Worksoft 
 
Worksoft,  the  industry  leader  in  continuous  test  automation  for  enterprise  applications, 
continues  to  be  a  top  choice  for  global  enterprises  looking  to  accelerate  Agile-plus-DevOps 
initiatives and achieve true end-to-end business process automation at a massive scale. 
 
Worksoft  Certify  provides  an  Agile  testing  framework  that  enables  non-technical  users, 
developers  and  test  automation  professionals  to  work  together  in  an  Agile  fashion  and  easily 
integrate into DevOps tools, chains, and processes. 
 
Key Features: 
 
 ● Enable  Agile  adoption  by  building  automation  closer  to  development  sprint  when 
documentation is top of mind 
● Quickly identify and document existing business processes and variations 
● Achieve end-to-end business process testing across enterprise applications 
● Efficiently  keep  pace  with  complex  application  landscapes  and  frequent  application 
updates 
● Uncover  and  resolve  data  transfer  problems  and  system  issues  before  production 
outages occur 
 
#2) PractiTest 
 
PractiTest  is  used  as  a  test  management  tool  for  agile  testing.  It  is  easy  to  learn,  affordable  & 
flexible  and  helps  both  the  developers  and  testers.  PractiTest  includes  requirements, test runs, 
results,  issues,  reporting  and  provides  the  detailed  status  of  your  project.  It  manages 
development and testing processes and has control of each and every task. 
 
PractiTest  provides  information  to  different  stakeholders  –  developers,  testers,  senior 
management,  etc  in  the  way  in  which  they  require.  It  has  the  capability  to display information 
in multiple ways at a glance. 
 
Key Features: 
 
● It can be integrated with tools like JIRA, Jenkins, Selenium, TestComplete etc. 
● It has a hierarchical tree structure to manage and find information. 
● The powerful and customized dashboard provides relevant and accurate information. 
● Easily imports existing data. 
● Complex database queries can be easily generated. 
● Creates manual tests and organizes based on sprints. 
● PractiTest has the capability to create bug directly from the test run. 
 
 
#3) JunoOne 
 
JunoOne  is  a  Great  tool for Agile Test Case Management and Issue Tracking with powerful JIRA 
integration. 
 
Work  efficiently  with  sophisticated  Test  Case  Management  system  JunoOne,  designed  to 
streamline  Test  Management  and  Incident  management.  Test  Management Software JunoOne 
offers  a  number  of  tools  that  will  make  all  the  testing  activities  well  arranged,  help  organize 
your work, control the individual steps and the overall state of the projects. 
 
JunoOne  offers  several  features  throughout  the  whole  process.  It  starts  with  creating  the 
campaign  and  performing  test  analysis.  Then  you  plan  to  test  and  run  the  tests.  Last  but  not 
least, it solves the issues and protects your data. 
 
#4) JIRA 
 
JIRA  is  an  Agile  Testing  as well as a Project Management Tool developed by Atlassian.  Atlassian 
Corporation  Plc  is  a  software  company  that  develops  products  for  project  managers,  software 
developers, etc. Atlassian was launched in 2002 with its headquarter in Sydney, Australia. 
 
Its  revenue  was  around  $620  million  in  2017  with  a  total  employee  count  of  around  2,200  and 
serves  around  60K  customers  across  the  globe.  Atlassian is well known for its tool – JIRA which 
is  used  for  defect  tracking,  planning,  reports,  and  managing  all  agile  software  development 
projects. 
 
Key Features: 
 
● JIRA supports an agile methodology like Scrum, Kanban, etc. 
● It  has  a  strong  reporting  feature  which  provides  access  to  dozens  of  reports  with 
real-time team performance. 
● Plans and forecasts roadmap and are able to make informed decisions. 
● Customized filters using JIRA Query Language. 
● It can be integrated with the developer tools for end to end traceability. 
 
#5) TestRail 
 
TestRail  is  a  modern  Agile  Testing  Tool  owned  by  Gurock  Software  Company.  Gurock  was 
launched  in  2004  with  its  headquarters  in  Berlin,  Germany.  Gurock  Software  specializes  in 
software  development  and  QA.  Products  developed  at  Gurock  are  helpful  for  customers 
worldwide to build their software. 
 
Currently,  many  large-scale  organizations  such  as  Microsoft,  Dell, Oracle, Intel, HP, Adobe etc 
are  using  their  products.  TestRail  is  a  web-based  tool  used  by the testing team to manage Agile 
Testing  Efforts.  TestRail  is  specifically  designed  for  the  purpose  of  supporting  an  agile  project 
milestone using sprints, various reports, and metrics. 
 
Key Features: 
 
● TestRail  manages  test  cases,  test  runs,  track  test  results  and  manages  entire  Testing 
efforts. 
● TestRail integrates with automation tools like JIRA, Jenkins, and Selenium. 
● Using its cloud edition, you can use it without installation or set-up. 
● Easily  selects  test  cases  based  on  the  filter  for  execution  and  stores  the  result  using  the 
modern interface. 
● Various  dashboard,  reports,  and  email  notifications keep the user informed throughout 
the testing cycle. 
● It can be integrated with Bugzilla, GitHub, Rally, TFS, FogBugz etc. 
 
 
#6) SoapUI 
 
SoapUI  is  an  agile  testing  tool  and  is  the  most  advanced  REST  and  Service  Oriented 
Architecture  (SOA)  which  was  developed  by  SmartBear.  SmartBear  is  a  Software  Information 
Technology Company, which was launched in 2009 with its headquarters in Boston, USA. 
 
SoapUI  is  basically  used  for  functional  testing  of  web  services.  This  includes  web  service 
development,  invoking  of  web  services,  etc. Using SoapUI, Test cases are easily created for web 
services.  It  has  strong  a  GUI  which  helps  to  execute  tests  and  analyze  the  reports  in  the  GUI 
itself. 
 
Key Features: 
 
● SoapUI is a free and open source tool. 
● SoapUI supports SOAP web service functional testing and REST API functional testing. 
● It allows to create and execute functional, regression and load tests. 
● Test cases can be easily created using drag and drop interface. 
● SoapUI provides complete test coverage and supports all standard protocols. 
● It supports multiple environment and data-driven testing. 
 
#7) VersionOne 
 
VersionOne  was  launched  in  2002  but  as  of  2017,  it  is  acquired  by  Collabnet  Inc.  VersionOne 
develops  agile  software solutions and services for fortune 100 companies. It is headquartered in 
Alpharetta, Georgia, and other offices are in Atlanta and Amsterdam. 
 
VersionOne  is  an  agile  testing  tool  as  well  as  an  Agile project management tool to support agile 
methodologies  such  as  Scrum,  Kanban  XP,  Lean,  etc.  It  provides  a  centralized  view  of  the 
backlog with drag and drop interface. 
 
 
Key Features: 
 
VersionOne provides centralized project management and improves the project visibility. 
Stories and epics can be managed across multiple projects and project teams. 
Easily  defines  and  tracks  delivery  across  all  the  projects  and  project  has the visibility across the 
entire project lifecycle. 
It allows the user to prioritize stories and defects using drag and drop interface. 
VersionOne can be integrated with JIRA, Jenkins, TFS, GitHub, etc 
 
#8) Selenium WebDriver 
 
Selenium  WebDriver  is  an  agile  automation  tool  which  is  widely  used  across  the  software 
industry.  In  today’s  technology,  the  word  “Agile”  and  “Automation”  are  used  frequently  due  to 
their huge advantages. 
 
It  is  truly  required  in  the  software  industry  to  run  any  project  in  agile  methodology  and  run 
repeatable tests using automation – Selenium WebDriver for a web-based application. 
 
Selenium  WebDriver  is  used  very  often  in  many  agile  projects  as  every  team  member  can 
contribute to automating the test cases. 
 
Key Features: 
 
● Selenium WebDriver is used only to automate browser-based application and it does not 
support desktop based applications. 
● Keyword driven framework can be easily built using Selenium WebDriver 
● Simulates  how  an  actual  user  can  interact  with  the  application  using  automated  test 
cases. 
● It  supports  JAVA,  C#,  Python,  Ruby,  PHP  programming  languages  to write automation 
scripts. 
 
#9) JMeter 
 
Apache  JMeter  is  an  agile  performance  testing  tool  written  in  JAVA  language.  It  is  designed  to 
measure  the  performance  of  an  application  and  its  functional  behavior  under  a  specific  load. 
Using JMeter you can simulate a heavy load on the web server and analyze its performance. 
 
Key Features: 
 
● JMeter is an open source tool. 
● Graphical  analysis  is  possible  for  the  performance  measurement  of  the  application 
under different types of load. 
● Ability to perform Load and Performance testing on different applications, servers etc. 
● Extended plug-in support for data analysis and visualization. 
● JMeter  can  be  used  for  static  and  dynamic resources like Servlets, Java Objects, and FTP 
servers to measure their performance. 
 
#10) qTest Scenario 
 
qTest  Scenario  is  a  JIRA  plug-in  which  is  used for agile testing. It helps the project team to take 
a  test-first  approach  in  agile  testing.  qTest  Scenario  manages  the  creation  of  test  cases, 
execution, defect tracking and results. 
 
Key Features: 
 
● It is built specifically for BDD, TDD and ATDD approach. 
● Can easily import and export the existing files. 
● It provides Gherkin editor for scenario and feature development. 
 ● Test  scenarios  can  be  executed  using  manual  method  through  JIRA  interface  or  using 
automation through Maven or Ruby. 
● Analyzes test coverage and features. 
● It can create custom reporting using JIRA and can compare velocity reporting. 
● For automated test results, it can be integrated with Cucumber via Maven. 
 

What is Agile Testing? 

Unlike  the  WaterFall  method, Agile Testing can begin at the start of the project with continuous 
integration  between  development  and  testing.  Agile  Testing  is  not  sequential  (in  the  sense  it's 
executed only after coding phase) but continuous. 

An  agile  team  works  as  a  single  team  towards  a  common  objective  of  achieving  Quality.  Agile 
Testing  has  shorter  time  frames  called  iterations  (say  from  1  to  4  weeks).  This  methodology  is 
also  called  release,  or  delivery driven approach since it gives a better prediction on the workable 
products in short duration of time. 

Test Plan for Agile 

Unlike  the  waterfall  model,  in  an  agile  model,  a  test  plan  is  written  and  updated  for  every 
release.  The  agile  test  plan  includes  types  of  testing  done  in  that  iteration  like  test  data 
requirements,  infrastructure,  test  environments,  and  test  results.  Typical  test  plans  in  agile 
includes 

1. Testing Scope 
2. New functionalities which are being tested 
3. Level or Types of testing based on the features complexity 
4. Load and Performance Testing 
5. Infrastructure Consideration 
6. Mitigation or Risks Plan 
7. Resourcing 
8. Deliverables and Milestones 

Agile Testing Strategies 

Agile testing life cycle spans through four stages 
  

(a) Iteration 0 

During  the  first  stage  or  iteration  0,  you  perform  initial  setup  tasks.  It  includes  identifying 
people  for  testing,  installing  testing  tools,  scheduling  resources  (usability  testing  lab),  etc.  The 
following steps are set to achieve in Iteration 0 

● Establishing a business case for the project 

● Establish the boundary conditions and the project scope 
● Outline the key requirements and use cases that will drive the design trade-offs 
● Outline one or more candidate architectures 
● Identifying the risk 
● Cost estimation and prepare a preliminary project 
● Construction Iterations 

The  second  phase  of  testing  is  Construction  Iterations,  ​the  majority  of  the  testing  occurs 
during  this  phase.  This  phase  is  observed  as  a  set  of  iterations  to  build  an  increment  of  the 
solution.  In  order  to  do  that,  within  each  iteration,  the  team  implements  a hybrid of practices 
from XP, Scrum, Agile modeling, and agile data and so on. 

In construction iteration, the agile team follows the prioritized requirement practice: With each 
iteration,  they  take  the  most  essential  requirements  remaining  from  the  work  item  stack  and 
implement them. 

Construction  iteration  is  classified  into  two,  confirmatory  testing  and  investigative  testing. 
Confirmatory  testing  concentrates  on  verifying  that  the  system  fulfills  the  intent  of  the 
stakeholders  as  described  to  the  team  to  date,  and  is  performed  by  the  team.  While  the 
investigative  testing  detects  the  problem  that  confirmatory  team  has  skipped  or  ignored.  In 
Investigative  testing,  tester  determines  the  potential  problems  in  the  form  of  defect  stories. 
Investigative  testing  deals  with  common issues like integration testing, load/stress testing, and 
security testing.  
Again,  confirmatory  testing  there  are  two  aspects  developer  testing  and  agile  acceptance 
testing.  Both  of  them  are  automated  to  enable  continuous  regression  testing  throughout  the 
lifecycle. Confirmatory testing is the agile equivalent of testing to the specification.  

Agile  acceptance  testing  is  a  combination  of  traditional  functional  testing  and  traditional 
acceptance  testing  as  the  development  team,  and  stakeholders  are  doing  it  together.  While 
developer  testing  is  a  mix  of  traditional  unit  testing  and traditional service integration testing. 
Developer testing verifies both the application code and the database schema. 

(c) Release End Game Or Transition Phase 

The  goal  of  “Release,  End  Game”  is  to  deploy  your  system  successfully  into  production.  The 
activities  included  in  this  phase  are  training  of  end  users,  support  people  and  operational 
people.  Also,  it  includes  marketing  of  the  product  release,  back-up  &  restoration,  finalization 
of system and user documentation. 

The  final  testing  stage  includes  full  system  testing  and  acceptance  testing.  In  accordance  to 
finish  your  final  testing  stage  without  any  obstacles,  you  should  have  to  test  the  product  more 
rigorously while it is in construction iterations. During the end game, testers will be working on 
its defect stories. 

(d) Production 

After the release stage, the product will move to the production stage. 

The Agile Testing Quadrants  

The  agile  testing  quadrants  separate  the  whole  process  in  four  Quadrants  and  help  to 
understand how agile testing is performed. 

a)  Agile  Quadrant  I  –  The  internal  code  quality  is  the  main  focus  in  this  quadrant,  and  it 
consists  of  test  cases  which  are  technology  driven  and  are  implemented  to support the team, it 
includes 
 ● 1. Unit Tests 
● 2.Component Tests 

b)  Agile  Quadrant  II  –  ​It  contains  test  cases  that  are  business  driven  and  are  implemented  to 
support  the  team.  This  Quadrant  focuses  on  the  requirements.  The  kind  of  test  performed  in 
this phase is 

● 1. Testing of examples of possible scenarios and workflows 

● 2. Testing of User experience such as prototypes 
● 3. Pair testing 

c)  Agile  Quadrant  III  –  This  quadrant  provides  feedback  to  quadrants  one  and  two.  The  test 
cases  can  be  used as the basis to perform automation testing.  In this quadrant, many rounds of 
iteration  reviews  are  carried  out  which  builds  confidence  in  the  product.  The  kind  of  testing 
done in this quadrant is 

● 1. Usability Testing 
● 2. Exploratory Testing 
● 3. Pair testing with customers 
● 4. Collaborative testing 
● 5. User acceptance testing 

d)  Agile  Quadrant  IV  –  ​This quadrant concentrates on the non-functional requirements such as 

performance,  security,  stability,  etc.  With  the  help  of this quadrant, the application is made to 
deliver the non-functional qualities and expected value. 

● 1. Non-functional tests such as stress and performance testing 

● 2. Security testing with respect to authentication and hacking 
● 3. Infrastructure testing 
● 4. Data migration testing 
● 5. Scalability testing 
● 6. Load testing 

QA challenges with agile software development 

● a)  Chances  of  error  are  more  in  agile, as documentation is given less priority, eventually 
puts more pressure on QA team 
● b)  New  features  are  introduced  quickly,  which  reduces  the  available  time  for test teams 
to  identify  whether  the  latest features are according to the requirement and does it truly 
address the business suits 
● c) Testers are often required to play a semi-developer role 
● d) Test execution cycles are highly compressed 
● e) Very less time to prepare test plan 
● f) For regression testing, they will have minimal timing 
● g) Change in their role from being a gate-keeper of quality to being a partner in Quality 
 ● h)  Requirement  changes  and  updates  are  inherent  in  an  agile  method,  becoming  the 
biggest challenge for QA 

Risk of Automation in Agile Process 

● Automated  UI  provides a high level of confidence, but they are slow to execute, fragile to 

maintain  and  expensive  to  build.  Automation  may  not  significantly  improve  test 
productivity unless the testers know how to test 
● Unreliable  tests  are  a  major  concern  in  automated  testing.  Fixing  failing  tests  and 
resolving  issues  related  to  brittle  tests  should  be  a  top  priority  in  order  to  avoid  false 
positives 
● If  the  automated  test  are  initiated  manually  rather  than  through  CI  (Continuous 
Integration)  then  there  is  a  risk  that  they  are  not  regularly  running  and  therefore  may 
cause failing of tests 
● Automated  tests  are  not  a  replacement  for  an  exploratory manual testing. To obtain the 
expected quality of the product, a mixture of testing types and levels is required 
● Many  commercially  available  automation  tools  provide  simple  features  like  automating 
the  capture and replay of manual test cases. Such tool encourages testing through the UI 
and  leads  to  an  inherently  brittle  and  difficult  to  maintain  tests.  Also, storing test cases 
outside the version control system creates unnecessary complexity 
● In  order  to  save  time,  much  times  the  automation  test  plan  is  poorly  planned  or 
unplanned which results in the test fail 
● A  test  set  up  and  tear  down  procedures  are  usually  missed  out  during  test  automation, 
while  Performing  manual  testing,  a  test  set  up  and  tear  down  procedures  sounds 
seamless 
● Productivity  metrics  such  as  a  number  of  test  cases  created  or  executed  per  day  can  be 
terribly misleading, and could lead to making a large investment in running useless tests 
● Members  of  the  agile  automation  team  must  be  effective  consultants:  approachable, 
cooperative, and resourceful, or this system will quickly fail 
● Automation  may  propose  and  deliver  testing  solutions  that  require  too  much  ongoing 
maintenance relative to the value provided 
● Automated testing may lack the expertise to conceive and deliver effective solutions 
● Automated  testing  may  be  so  successful  that  they  run  out  of  important  problems  to 
solve, and thus turn to unimportant problems. 

 
TDD-  Test  Driven  Development,  Behaviour  Driven  Development  &  Acceptance  TestDriven 
Development 

First lets list out what exactly each methodology does means 

Test  Driven  Development  (TDD)  which  is  a  process  of  writing  tests  before  writing  code  and 
make  the test fail. Now write enough code so that test can pass and then at last refactor the code 
as  per your requirement and make sure the test is passing again after the change. This is it. This 
is  the  simplest  way  of  explaining  TDD  in  my  opinion.  Now,  the  main  focus  of  TDD  will  be  on 
testing  the  low-level  functionality  and  units  (for  single  classes  and  methods)  that  can  lead  to 
more  flexible  code  and  easier  refactoring.  In  a  simple language we can say, we write these tests 
to check if the code we wrote works fine. 

TDD 

Its  also  called  test-driven  design,  is  a  method  of  software  development  in  which  unit testing is 
repeatedly  done  on  source  code.  Write  your  tests  watch  it  fails  and  then  refactor  it.  After  each 
test,  refactoring  is  done  and  then  the  same  or  a  similar  test  is  performed  again.  The process is 
iterated  as  many  times  as  necessary  until  each  unit  is  functionally  working  as  expected.  TDD 
was introduced first by XP.  

BDD – Behaviour Driven Development 

Behavior-driven  development  combines  the  general  techniques  and  principles  of  TDD  with 
ideas from domain-driven design 

Behavior-Driven  Development  (BDD)  and  why  was  that  needed?  Well,  BDD  is  similar  in  many 
ways  to  TDD  except  that  the  word  “test”  is  replaced  with  the  word  “spec”.  Basically,  BDD 
focuses on the behaviors of your system exhibits than the implementation details of it. 

The  focus of BDD is the language and interactions used in the process of software development. 
Behavior-driven  developers  use  their  native  language  in  combination  with  the  language  of 
Domain  Driven  Design  to  describe  the  purpose  and  benefit  of  their  code.  This  allows  the 
developers to focus on “Does my code do what it’s supposed to do?” in addition to “Does my code 
work?” 

DDD-Domain Driven Testing 

BDD  is  similar  in  many  ways  to  TDD  except  that  the  word  “test”  is  replaced  with  the  word 
“Behaviour”.  It’s  purpose  is  to  help  the  folks  devising  the  system  (i.e.,  the  developer)  identify 
appropriate  tests  to  write–that  is,  tests  that  reflect  the  behavior  desired  by  the  stakeholders. 
BDD  is  usually  done  in  very  English-like  language  helps  the  Domain  experts to understand the 
implementation  rather  than  exposing  the  code  level  tests. Its defined in a GWT format, GIVEN 
WHEN & THEN. 

Dan North first introduced the BDD Style of methodology 

ATDD – Acceptance Test Driven Development. 

Acceptance  Test  Driven  Development  (ATDD)  that  adds  ‘A’  before  TDD  which  stands  for 
Acceptance.  Now,  why  was  this  even  needed? Wasn’t the TDD good enough and better? I would 
say  no  and  the  reason  was  that  TDD  was  more of telling to make sure the code works fine but it 
did  not  say  that  if  the  code  that  is  written  was  even  required  at  first  place.  In  ATDD  the 
acceptance  criteria  are  defined  in  early  in  application  development  process  and  then  those 
criteria can be used to guide the subsequent development work. 

ATDD  is  a  collaborative  exercise  that  involves  product  owners,  business  analysts,  testers,  and 
developers.  ATDD  helps  to  ensure  that  all  project  members understand precisely what needs to 
be done and implemented. 

ATDD  is  a  collaborative  practice  where  users,  testers,  and  developers  define  automated 
acceptance  criteria  early  in  the  development  process.  ATDD  helps  to  ensure  that  all  project 
members  understand  precisely  what  needs  to be done and implemented. This workflow usually 
involves  establishing  the  criteria  first,  most  often  from  a  user  perspective,  and  creating 
concrete  examples.  Thereafter,  acceptance  tests  are  developed  and  run  to  see  the  results  of 
failure  with  the  right  code  based  on  these  examples.  Minimal code is then developed to run the 
program,  more acceptance tests are run again, and the results are validated. Refactoring is then 
carried  out based on the results of the acceptance tests before the final program is developed for 
use. 

Few, Differences between TDD BDD FDD and ATDD 

● BDD  focuses  on  the  behavioural  aspect  of  the  system  rather  unlike  the  TDD  focuses  on 
the implementation aspect of the system. 
● ATDD  focuses  on  capturing  requirements in acceptance tests and uses them to drive the 
development.  It  seems  like  ATDD  focuses  on  external  quality  of  the  software  (does  the 
system do what it is required to do?). 
● ATDD  leans  towards  the  developer-focused  side of things like [Unit]TDD does, the BDD 
is where the step of making it more customer-focused comes in. 
● As  discussed  earlier,  the  immediate  obvious  difference  between  TDD  and  ATDD  is  the 
‘A’.  While  that  may  sound  sarcastic,  the  point  is  that  TDD  (as  usually  practiced)  has  an 
implied  U  on  the  front,  standing  for  Unit,  while  the  A  stands  for  Acceptance.  TDD 
focuses on the low level, ATDD on high level. 
 ● BDD  is  usually  done  in  very  English-like  language,  and  often with further tools to make 
it  easy  for  non-techies  to understand, like Fitnesse for example. This allows much easier 
collaboration with non-techie stakeholders, than TDD. 
● By  contrast,  TDD  tools  and  techniques  are  usually  much  more  techie  in  nature, 
requiring  that  you  become  familiar  with  the  detailed  object  model  (or  in  fact  create  the 
object  model  in  the  process,  if  doing  true  test-first  canonical  TDD).  The  typical 
non-programming  executive  stakeholder  would  be  utterly  lost  trying  to  follow  along 
with  TDD,  let  alone  participate,  and  frankly  shouldn’t  be  involved  with  that  level  of 
detail. 
● BDD  focuses  on  the  behavioural  aspect  of  the  system  rather  than  the  implementation 
aspect  of  the  system  that TDD focuses on. BDD gives a clearer understanding as to what 
the  system  should  do  from  the  perspective of the developer and the customer. TDD only 
gives the developer an understanding of what the system should do 
● FDD(Feature  Driven  Development)  is  a  method  to  develop  software.  FDD  recommends 
feature based development. The sprints, team and deliver is based on features 

Extreme  programming  (XP)  is  one  of  the  most  important software development framework of 

Agile  models.  It  is  used  to  improve  software  quality  and  responsive to customer requirements. 
The  extreme  programming  model  recommends  taking  the  best practices that have worked well 
in the past in program development projects to extreme levels. 

Good  practices  needs  to  practiced  extreme  programming: Some of the good practices that have 

been  recognized  in  the  extreme  programming  model  and  suggested  to  maximize  their  use  are 
given below: 

Code  Review: ​Code review detects and corrects errors efficiently. It suggests pair programming 
as  coding  and  reviewing  of  written  code  carried  out  by a pair of programmers who switch their 
works between them every hour. 

Testing:  ​Testing  code  helps  to  remove  errors  and  improves  its  reliability.  XP  suggests 
test-driven  development  (TDD)  to  continually  write  and  execute  test  cases.  In  the  TDD 
approach test cases are written even before any code is written. 

Incremental development: ​Incremental development is very good because customer feedback is 
gained  and  based  on  this  development  team come up with new increments every few days after 
each iteration. 

Simplicity:  ​Simplicity  makes  it  easier  to  develop  good  quality  code  as  well  as  to  test and debug 
it. 
Design:  ​Good  quality  design  is  important  to  develop  a  good  quality  software.  So,  everybody 
should design daily. 

Integration  testing:  ​It  helps  to  identify  bugs  at  the  interfaces  of  different  functionalities. 
Extreme  programming  suggests  that  the  developers  should  achieve  continuous  integration  by 
building and performing integration testing several times a day. 

Listening:  The  developers  needs  to  carefully  listen  to  the  customers  if  they  have  to  develop  a 
good  quality  software.  Sometimes  programmers  may  not  have  the  depth  knowledge  of  the 
system  to  be  developed.  So,  it  is  desirable  for  the  programmers  to  understand  properly  the 
functionality of the system and they have to listen to the customers. 

Designing:  Without  a  proper  design,  a  system  implementation  becomes  too  complex  and  very 
difficult  to  understand  the  solution,  thus  it  makes  maintenance  expensive.  A  good  design 
results  elimination  of  complex  dependencies  within  a  system.  So,  effective  use  of  suitable 
design is emphasized. 

Feedback:  ​One  of the most important aspects of the XP model is to gain feedback to understand 

the  exact  customer  needs.  Frequent  contact  with  the  customer  makes  the  development 
effective. 

Basic principles of Extreme programming:  

XP  is  based  on  the  frequent  iteration  through  which  the  developers  implement  User  Stories. 
User  stories  are  simple  and  informal  statements  of  the  customer  about  the  functionalities 
needed.  A  User  story  is  a  conventional  description  by  the  user  about  a  feature  of  the  required 
system.  It  does  not  mention  finer  details  such  as  the  different  scenarios that can occur. On the 
basis  of  User  stories,  the  project  team  proposes  Metaphors.  Metaphors are a common vision of 
how  the  system  would  work.  The  development  team  may  decide  to  build  a  Spike  for  some 
feature.  A  Spike  is  a  very  simple  program  that  is  constructed  to  explore  the  suitability  of  a 
solution being proposed. It can be considered similar to a prototype.  

Applications  of  Extreme  Programming  (XP):  Some  of  the  projects  that  are suitable to develop 
using XP model are given below: 

Small  projects:  ​XP  model  is  very  useful  in  small  projects  consisting  of  small  teams  as  face  to 
face meeting is easier to achieve. 

Projects  involving  new  technology  or  Research  projects:  This  type  of  projects  face  changing 
requirements  rapidly  and  technical  problems.  So  XP  model  is  used  to  complete  this  type  of 
projects. 
 

MODULE 2 

Definition of Scrum 

Scrum  (n):  ​A  framework  within  which  people  can  address  complex  adaptive  problems,  while 
productively and creatively delivering products of the highest possible value. 

Scrum is: Lightweight, Simple to understand, Difficult to master 

Scrum  is  a  process  framework  that  has  been  used  to  manage  work  on  complex  products  since 
the  early  1990s.  Scrum  is  not  a  process,  technique,  or  definitive  method.  Rather,  it  is  a 
framework  within  which  you  can  employ  various processes and techniques. Scrum makes clear 
the  relative  efficacy  of  your  product  management  and  work  techniques  so  that  you  can 
continuously improve the product, the team, and the working environment. 

The  Scrum  framework  consists  of  Scrum  Teams  and  their  associated  roles,  events,  artifacts, 
and  rules.  Each  component  within  the  framework  serves  a  specific  purpose  and  is  essential  to 
Scrum’s success and usage. 

The  rules  of  Scrum  bind  together  the  roles,  events,  and  artifacts,  governing  the  relationships 
and  interaction  between  them.  The  rules  of  Scrum  are  described  throughout  the  body  of  this 
document. Specific tactics for using the Scrum framework vary and are described elsewhere. 

Uses of Scrum 

Scrum  was  initially  developed  for  managing  and  developing  products.  Starting  in  the  early 
1990s, Scrum has been used extensively, worldwide, to: 

● Research and identify viable markets, technologies, and product capabilities; 

● Develop products and enhancements; 
● Release products and enhancements, as frequently as many times per day; 
● Develop  and  sustain  Cloud  (online,  secure,  on-demand)  and  other  operational 
environments for product use; and, 
● Sustain and renew products. 

Scrum  has  been  used  to  develop  software,  hardware,  embedded  software,  networks  of 
interacting  function,  autonomous  vehicles,  schools,  government,  marketing,  managing  the 
operation  of  organizations  and  almost  everything  we  use  in  our  daily  lives,  as  individuals  and 
societies. 

As  technology,  market,  and  environmental  complexities  and  their  interactions  have  rapidly 
increased, Scrum’s utility in dealing with complexity is proven daily. 

Scrum  proved  especially  effective  in  iterative  and  incremental  knowledge  transfer.  Scrum  is 
now widely used for products, services, and the management of the parent organization. 

The  essence  of  Scrum  is  a  small  team  of  people.  The  individual  team  is  highly  flexible  and 
adaptive.  These  strengths  continue  operating  in  single,  several,  many,  and  networks  of  teams 
that  develop,  release,  operate  and  sustain  the  work  and  work  products  of  thousands of people. 
They  collaborate  and  inter-operate through sophisticated development architectures and target 
release environments. 

When  the  words  "develop"  and  "development"  are  used  in  the  Scrum  Guide,  they  refer  to 
complex work, such as those types identified above. 

Scrum Theory 

Scrum  is  founded  on  empirical  process  control  theory,  or  empiricism.  Empiricism  asserts that 
knowledge  comes  from  experience  and  making  decisions  based  on  what  is  known.  Scrum 
employs  an  iterative,  incremental  approach  to  optimize  predictability  and  control  risk.  Three 
pillars uphold every implementation of empirical process control: transparency, inspection, and 
adaptation. 

Transparency 

Significant  aspects  of  the  process  must  be  visible  to  those  responsible  for  the  outcome. 
Transparency  requires  those  aspects  be  defined  by  a  common  standard  so  observers  share  a 
common understanding of what is being seen. 

For example: 

A common language referring to the process must be shared by all participants; and, 

Those  performing  the work and those inspecting the resulting increment must share a common 

definition of "Done". 
Inspection 

Scrum  users  must  frequently  inspect  Scrum  artifacts  and  progress  toward  a  Sprint  Goal  to 
detect  undesirable  variances.  Their  inspection  should  not  be so frequent that inspection gets in 
the  way  of  the  work.  Inspections  are  most  beneficial  when  diligently  performed  by  skilled 
inspectors at the point of work. 

Adaptation 

If  an  inspector  determines  that  one  or  more  aspects  of  a  process  deviate  outside  acceptable 
limits,  and  that  the  resulting  product  will  be  unacceptable,  the  process  or  the  material  being 
processed  must  be  adjusted.  An  adjustment  must  be  made  as  soon  as  possible  to  minimize 
further deviation. 

Scrum prescribes five formal events for inspection and adaptation 

● Sprint Planning 
● Daily Scrum 
● Sprint Review 
● Sprint Retrospective 
● Scrum Values 

When  the  values  of  commitment,  courage, focus, openness and respect are embodied and lived 

by  the  Scrum  Team,  the  Scrum  pillars  of  transparency,  inspection,  and adaptation come to life 
and  build  trust  for  everyone.  The  Scrum  Team  members  learn  and  explore  those values as they 
work with the Scrum events, roles and artifacts. 

Successful  use  of  Scrum  depends  on  people  becoming  more  proficient  in  living  these  five 
values.  People  personally  commit  to  achieving  the  goals  of  the  Scrum  Team.  The  Scrum  Team 
members  have  the  courage to do the right thing and work on tough problems. Everyone focuses 
on  the  work  of  the  Sprint  and  the  goals  of  the  Scrum  Team.  The  Scrum  Team  and  its 
stakeholders  agree  to  be  open  about  all  the  work  and  the  challenges with performing the work. 
Scrum Team members respect each other to be capable, independent people. 

The Scrum Team 

The  Scrum  Team  consists  of  a  Product  Owner,  the  Development  Team,  and  a  Scrum  Master. 
Scrum  Teams  are  self-organizing  and  cross-functional.  Self-organizing teams choose how best 
to  accomplish  their  work,  rather  than  being  directed  by  others  outside  the  team. 
Cross-functional  teams  have  all  competencies  needed  to  accomplish  the  work  without 
depending  on  others  not  part  of  the  team.  The  team  model  in  Scrum  is  designed  to  optimize 
flexibility,  creativity,  and  productivity.  The  Scrum  Team  has  proven  itself  to  be  increasingly 
effective for all the earlier stated uses, and any complex work. 

Scrum  Teams  deliver  products  iteratively  and  incrementally,  maximizing  opportunities  for 
feedback.  Incremental  deliveries  of  "Done"  product  ensure  a  potentially  useful  version  of 
working product is always available. 

The Product Owner 

The  Product  Owner  is  responsible  for  maximizing  the value of the product resulting from work 

of  the  Development  Team.  How  this  is  done  may  vary  widely  across  organizations,  Scrum 
Teams, and individuals. 

The  Product  Owner  is  the  sole  person  responsible  for  managing  the  Product  Backlog.  Product 
Backlog management includes: 

● Clearly expressing Product Backlog items; 

● Ordering the items in the Product Backlog to best achieve goals and missions; 
● Optimizing the value of the work the Development Team performs; 
● Ensuring  that  the  Product  Backlog  is  visible,  transparent,  and  clear  to  all,  and  shows 
what the Scrum Team will work on next; and, 
● Ensuring  the  Development  Team  understands  items  in  the  Product  Backlog  to  the level 
needed. 

The  Product  Owner  may  do  the above work, or have the Development Team do it. However, the 

Product Owner remains accountable. 

The  Product  Owner  is  one  person,  not  a  committee.  The  Product  Owner  may  represent  the 
desires  of  a  committee  in  the  Product  Backlog,  but  those  wanting  to  change a Product Backlog 
item’s priority must address the Product Owner. 

For  the  Product  Owner  to  succeed,  the  entire  organization  must  respect  his  or  her  decisions. 
The  Product  Owner’s  decisions  are  visible  in  the  content  and  ordering  of  the  Product  Backlog. 
No one can force the Development Team to work from a different set of requirements. 

The Development Team 

The  Development  Team  consists  of  professionals  who  do  the  work  of  delivering  a  potentially 
releasable  Increment  of  "Done"  product  at  the  end  of  each  Sprint.  A  "Done"  increment  is 
required at the Sprint Review. Only members of the Development Team create the Increment. 
Development  Teams  are  structured  and  empowered  by  the  organization  to  organize  and 
manage  their  own  work.  The  resulting  synergy  optimizes  the  Development  Team’s  overall 
efficiency and effectiveness. 

Development Teams have the following characteristics: 

● They  are  self-organizing.  No  one  (not  even  the  Scrum  Master)  tells  the  Development 
Team  how  to  turn  Product  Backlog  into  Increments  of  potentially  releasable 
functionality; 
● Development  Teams are cross-functional, with all the skills as a team necessary to create 
a product Increment; 
● Scrum  recognizes  no  titles  for  Development  Team  members,  regardless  of  the  work 
being performed by the person; 
● Scrum  recognizes  no  sub-teams  in  the  Development  Team,  regardless  of  domains  that 
need to be addressed like testing, architecture, operations, or business analysis; and, 
● Individual  Development  Team  members  may  have  specialized  skills  and  areas  of  focus, 
but accountability belongs to the Development Team as a whole. 

Development Team Size 

Optimal  Development  Team  size  is  small  enough  to  remain  nimble  and  large  enough  to 
complete  significant  work  within  a  Sprint.  Fewer  than  three  Development  Team  members 
decrease  interaction  and  results  in  smaller  productivity  gains.  Smaller  Development  Teams 
may  encounter  skill  constraints  during  the  Sprint,  causing the Development Team to be unable 
to  deliver  a  potentially  releasable  Increment.  Having  more  than  nine  members  requires  too 
much  coordination.  Large  Development  Teams  generate  too  much  complexity  for an empirical 
process  to  be  useful.  The  Product  Owner  and  Scrum Master roles are not included in this count 
unless they are also executing the work of the Sprint Backlog. 

The Scrum Master 

The  Scrum  Master  is  responsible  for  promoting  and supporting Scrum as defined in the Scrum 

Guide.  Scrum  Masters  do  this  by  helping  everyone  understand  Scrum  theory,  practices,  rules, 
and values. 

The  Scrum  Master  is  a  servant-leader  for  the  Scrum  Team.  The  Scrum  Master  helps  those 
outside  the  Scrum  Team  understand  which  of  their  interactions  with  the  Scrum  Team  are 
helpful  and  which  aren’t.  The  Scrum  Master  helps  everyone  change  these  interactions  to 
maximize the value created by the Scrum Team. 

Scrum Master Service to the Product Owner 

The Scrum Master serves the Product Owner in several ways, including: 

● Ensuring  that  goals,  scope,  and  product  domain  are  understood  by  everyone  on  the 
Scrum Team as well as possible; 
● Finding techniques for effective Product Backlog management; 
● Helping  the  Scrum  Team  understand  the  need  for  clear  and  concise  Product  Backlog 
items; 
● Understanding product planning in an empirical environment; 
● Ensuring  the  Product  Owner  knows  how  to  arrange  the  Product  Backlog  to  maximize 
value; 
● Understanding and practicing agility; and, 
● Facilitating Scrum events as requested or needed. 
● Scrum Master Service to the Development Team 

The Scrum Master serves the Development Team in several ways, including: 

● Coaching the Development Team in self-organization and cross-functionality; 

● Helping the Development Team to create high-value products; 
● Removing impediments to the Development Team’s progress; 
● Facilitating Scrum events as requested or needed; and, 
● Coaching  the  Development  Team  in organizational environments in which Scrum is not 
yet fully adopted and understood. 

Scrum Master Service to the Organization 

The Scrum Master serves the organization in several ways, including: 

● Leading and coaching the organization in its Scrum adoption; 

● Planning Scrum implementations within the organization; 
● Helping  employees  and  stakeholders  understand  and  enact  Scrum  and  empirical 
product development; 
● Causing change that increases the productivity of the Scrum Team; and, 
● Working  with  other  Scrum  Masters  to  increase  the  effectiveness  of  the  application  of 
Scrum in the organization. 

Scrum Events 

Prescribed  events  are  used  in Scrum to create regularity and to minimize the need for meetings 

not  defined  in  Scrum.  All  events  are  time-boxed  events,  such  that  every  event  has  a  maximum 
duration.  Once  a  Sprint  begins,  its  duration  is  fixed  and  cannot  be  shortened  or  lengthened. 
The  remaining  events  may  end  whenever  the  purpose  of  the  event  is  achieved,  ensuring  an 
appropriate amount of time is spent without allowing waste in the process. 
Other  than  the  Sprint  itself,  which  is  a  container  for  all  other  events,  each  event  in  Scrum  is  a 
formal  opportunity  to  inspect  and  adapt  something.  These  events  are  specifically  designed  to 
enable  critical  transparency  and  inspection.  Failure  to  include  any  of  these  events  results  in 
reduced transparency and is a lost opportunity to inspect and adapt. 

The Sprint 

The  heart  of  Scrum  is  a  Sprint,  a  time-box  of  one  month  or less during which a "Done", usable, 
and  potentially  releasable  product  Increment  is  created.  Sprints  have  consistent  durations 
throughout  a  development  effort.  A  new  Sprint  starts  immediately  after  the  conclusion  of  the 
previous Sprint. 

Sprints  contain  and  consist  of  the  Sprint  Planning,  Daily  Scrums,  the  development  work,  the 
Sprint Review, and the Sprint Retrospective. 

During the Sprint: 

1. No changes are made that would endanger the Sprint Goal; 

2. Quality goals do not decrease; and, 
3. Scope  may  be  clarified  and  re-negotiated between the Product Owner and Development 
Team as more is learned. 

Each  Sprint may be considered a project with no more than a one-month horizon. Like projects, 
Sprints  are  used to accomplish something. Each Sprint has a goal of what is to be built, a design 
and flexible plan that will guide building it, the work, and the resultant product increment. 

Sprints  are  limited  to  one  calendar month. When a Sprint’s horizon is too long the definition of 

what  is  being  built  may  change,  complexity  may  rise,  and  risk  may  increase.  Sprints  enable 
predictability  by  ensuring  inspection  and  adaptation  of  progress  toward  a  Sprint  Goal  at  least 
every calendar month. Sprints also limit risk to one calendar month of cost. 

Cancelling a Sprint 

● A  Sprint  can  be  cancelled  before  the  Sprint  time-box  is  over.  Only  the  Product  Owner 
has  the  authority  to  cancel  the  Sprint,  although  he  or  she  may  do  so  under  influence 
from the stakeholders, the Development Team, or the Scrum Master. 
● A  Sprint  would  be  cancelled  if  the  Sprint  Goal becomes obsolete. This might occur if the 
company  changes  direction  or  if  market  or  technology  conditions  change.  In  general, a 
Sprint  should  be  cancelled  if it no longer makes sense given the circumstances. But, due 
to the short duration of Sprints, cancellation rarely makes sense. 
● When  a  Sprint  is  cancelled,  any  completed  and  "Done"  Product  Backlog  items  are 
reviewed.  If  part  of  the  work  is  potentially  releasable,  the  Product  Owner  typically 
accepts  it.  All  incomplete  Product  Backlog  Items  are  re-estimated  and  put  back  on  the 
 Product  Backlog.  The  work  done  on  them  depreciates  quickly  and  must  be  frequently 
re-estimated. 
● Sprint  cancellations  consume  resources,  since  everyone  regroups  in  another  Sprint 
Planning  to  start  another  Sprint.  Sprint  cancellations  are  often  traumatic  to  the  Scrum 
Team, and are very uncommon. 

Sprint Planning 

The  work  to  be  performed  in  the  Sprint  is  planned  at  the  Sprint  Planning.  This  plan  is  created 
by the collaborative work of the entire Scrum Team. 

Sprint  Planning  is  time-boxed  to  a  maximum  of  eight  hours  for  a  one-month  Sprint.  For 
shorter  Sprints,  the  event  is  usually  shorter.  The  Scrum  Master  ensures  that  the  event  takes 
place  and  that  attendants  understand  its  purpose.  The  Scrum  Master  teaches  the  Scrum  Team 
to keep it within the time-box. 

Sprint Planning answers the following: 

● What can be delivered in the Increment resulting from the upcoming Sprint? 
● How will the work needed to deliver the Increment be achieved? 

The  Development  Team  usually  starts  by  designing  the  system  and  the  work needed to convert 
the  Product  Backlog  into  a  working  product  Increment.  Work  may  be  of  varying  size,  or 
estimated  effort.  However,  enough  work  is  planned  during  Sprint  Planning  for  the 
Development  Team  to  forecast  what  it believes it can do in the upcoming Sprint. Work planned 
for  the  first  days  of  the  Sprint  by  the  Development  Team  is  decomposed  by  the  end  of  this 
meeting,  often  to  units  of  one  day  or  less.  The  Development  Team  self-organizes  to  undertake 
the  work  in  the  Sprint  Backlog,  both  during  Sprint  Planning  and  as  needed  throughout  the 
Sprint. 

The  Product  Owner  can  help  to  clarify  the selected Product Backlog items and make trade-offs. 

If  the  Development  Team  determines  it  has  too  much  or  too  little  work,  it  may renegotiate the 
selected  Product  Backlog  items  with  the  Product  Owner.  The  Development  Team  may  also 
invite other people to attend to provide technical or domain advice. 

By  the  end  of  the  Sprint  Planning,  the  Development  Team  should  be  able  to  explain  to  the 
Product  Owner  and  Scrum  Master  how  it  intends  to  work  as  a  self-organizing  team  to 
accomplish the Sprint Goal and create the anticipated Increment. 

Sprint Goal 
The  Sprint  Goal  is  an objective set for the Sprint that can be met through the implementation of 
Product  Backlog.  It  provides  guidance  to  the  Development  Team  on  why  it  is  building  the 
Increment.  It  is  created  during  the  Sprint  Planning  meeting.  The  Sprint  Goal  gives  the 
Development  Team  some  flexibility regarding the functionality implemented within the Sprint. 
The  selected  Product  Backlog  items  deliver  one  coherent  function,  which  can  be  the  Sprint 
Goal.  The  Sprint  Goal  can  be  any  other  coherence  that  causes  the  Development  Team  to  work 
together rather than on separate initiatives. 

As  the  Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint 

Goal,  it  implements  functionality  and  technology.  If  the work turns out to be different than the 
Development  Team  expected, they collaborate with the Product Owner to negotiate the scope of 
Sprint Backlog within the Sprint. 

Daily Scrum 

The  Daily  Scrum  is  a  15-minute  time-boxed  event  for  the  Development Team. The Daily Scrum 
is  held  every  day  of  the  Sprint.  At  it,  the  Development  Team  plans  work  for  the  next  24  hours. 
This  optimizes  team  collaboration  and  performance  by  inspecting  the  work  since the last Daily 
Scrum  and  forecasting  upcoming  Sprint  work.  The  Daily  Scrum  is  held  at  the  same  time  and 
place each day to reduce complexity. 

The  Development  Team  uses  the  Daily Scrum to inspect progress toward the Sprint Goal and to 

inspect  how  progress  is  trending  toward  completing  the  work  in  the  Sprint  Backlog.  The Daily 
Scrum  optimizes  the  probability  that  the  Development  Team  will  meet  the  Sprint  Goal.  Every 
day,  the  Development  Team  should  understand  how  it  intends  to  work  together  as  a 
self-organizing  team  to  accomplish the Sprint Goal and create the anticipated Increment by the 
end of the Sprint. 

The  structure  of  the  meeting  is  set by the Development Team and can be conducted in different 

ways  if  it  focuses  on  progress  toward  the  Sprint  Goal.  Some  Development  Teams  will  use 
questions, some will be more discussion based. Here is an example of what might be used: 

● What did I do yesterday that helped the Development Team meet the Sprint Goal? 
● What will I do today to help the Development Team meet the Sprint Goal? 
● Do  I  see  any  impediment  that  prevents  me  or  the  Development Team from meeting the 
Sprint Goal? 

The  Development  Team  or  team  members  often  meet  immediately  after  the  Daily  Scrum  for 
detailed discussions, or adapt, or replan, the rest of the Sprint’s work. 
The  Scrum  Master  ensures  that  the  Development  Team  has  the  meeting,  but  the  Development 
Team  is  responsible  for  conducting  the  Daily  Scrum.  The  Scrum  Master  teaches  the 
Development Team to keep the Daily Scrum within the 15-minute time-box. 

The  Daily  Scrum  is  an  internal  meeting  for  the  Development  Team.  If  others  are  present,  the 
Scrum Master ensures that they do not disrupt the meeting. 

Daily  Scrums  improve  communications,  eliminate  other  meetings,  identify  impediments  to 
development  for  removal,  highlight  and  promote  quick  decision-making,  and  improve  the 
Development Team’s level of knowledge. This is a key inspect and adapt meeting. 

Sprint Review 

A  Sprint  Review  is  held  at  the  end  of  the Sprint to inspect the Increment and adapt the Product 

Backlog  if  needed.  During  the  Sprint  Review,  the  Scrum  Team  and  stakeholders  collaborate 
about  what  was  done  in  the  Sprint.  Based  on  that  and  any  changes  to  the  Product  Backlog 
during  the  Sprint,  attendees  collaborate  on  the  next  things  that  could  be  done  to  optimize 
value.  This  is  an  informal  meeting, not a status meeting, and the presentation of the Increment 
is intended to elicit feedback and foster collaboration. 

This  is  at  most  a  four-hour  meeting  for  one-month  Sprints.  For  shorter  Sprints,  the  event  is 
usually  shorter.  The  Scrum  Master  ensures  that  the  event  takes  place  and  that  attendees 
understand  its  purpose.  The  Scrum  Master  teaches  everyone  involved  to  keep  it  within  the 
time-box. 

The Sprint Review includes the following elements: 

1. Attendees include the Scrum Team and key stakeholders invited by the Product Owner; 
2. The Product Owner explains what Product Backlog items have been "Done" and what has 
not been "Done"; 
3. The  Development  Team  discusses  what  went  well  during  the  Sprint,  what  problems  it 
ran into, and how those problems were solved; 
4. The  Development  Team  demonstrates  the  work  that  it  has  "Done"  and  answers 
questions about the Increment; 
5. The  Product  Owner  discusses  the  Product  Backlog  as  it  stands.  He or she projects likely 
target and delivery dates based on progress to date (if needed); 
6. The  entire  group  collaborates  on  what  to  do  next,  so  that  the  Sprint  Review  provides 
valuable input to subsequent Sprint Planning; 
7. Review  of  how the marketplace or potential use of the product might have changed what 
is the most valuable thing to do next; and, 
8. Review  of  the  timeline,  budget,  potential  capabilities,  and  marketplace  for  the  next 
anticipated releases of functionality or capability of the product. 
The  result  of  the  Sprint  Review  is  a  revised  Product  Backlog  that  defines  the  probable  Product 
Backlog  items  for  the  next  Sprint.  The  Product  Backlog  may  also  be  adjusted  overall  to  meet 
new opportunities. 

Sprint Retrospective 

The  Sprint  Retrospective  is  an  opportunity  for  the  Scrum  Team  to  inspect  itself  and  create  a 
plan for improvements to be enacted during the next Sprint. 

The  Sprint  Retrospective  occurs  after  the  Sprint  Review  and  prior  to  the  next  Sprint  Planning. 
This  is  at  most  a  three-hour  meeting  for  one-month  Sprints.  For  shorter  Sprints,  the  event  is 
usually  shorter.  The  Scrum  Master  ensures  that  the  event  takes  place  and  that  attendants 
understand its purpose. 

The  Scrum  Master  ensures  that  the  meeting  is  positive  and  productive.  The  Scrum  Master 
teaches  all  to  keep  it  within  the  time-box.  The  Scrum  Master  participates  as  a  peer  team 
member in the meeting from the accountability over the Scrum process. 

The purpose of the Sprint Retrospective is to: 

1. Inspect  how  the  last  Sprint  went  with  regards  to  people,  relationships,  process,  and 
tools; 
2. Identify and order the major items that went well and potential improvements; and, 
3. Create  a  plan  for  implementing  improvements  to  the  way  the  Scrum  Team  does  its 
work. 

The  Scrum  Master  encourages  the  Scrum  Team  to  improve,  within  the  Scrum  process 
framework,  its  development  process  and  practices  to  make  it  more  effective  and  enjoyable  for 
the  next  Sprint.  During  each  Sprint  Retrospective,  the  Scrum  Team  plans  ways  to  increase 
product  quality  by  improving  work  processes  or  adapting  the  definition  of  "Done",  if 
appropriate and not in conflict with product or organizational standards. 

By  the  end  of  the  Sprint  Retrospective,  the  Scrum  Team  should  have  identified  improvements 
that  it  will  implement  in  the  next  Sprint.  Implementing these improvements in the next Sprint 
is  the  adaptation  to  the  inspection  of  the  Scrum  Team  itself.  Although  improvements  may  be 
implemented  at  any  time,  the  Sprint  Retrospective  provides  a  formal  opportunity  to  focus  on 
inspection and adaptation. 

Scrum Artifacts 
Scrum’s  artifacts  represent  work  or  value  to  provide  transparency  and  opportunities  for 
inspection  and  adaptation.  Artifacts  defined  by  Scrum  are  specifically  designed  to  maximize 
transparency of key information so that everybody has the same understanding of the artifact. 

Product Backlog 

The  Product  Backlog  is  an  ordered  list  of  everything  that  is known to be needed in the product. 
It  is  the  single  source  of  requirements  for  any  changes  to  be  made  to  the product. The Product 
Owner is responsible for the Product Backlog, including its content, availability, and ordering. 

A  Product  Backlog  is  never  complete.  The  earliest  development of it lays out the initially known 

and  best-understood  requirements.  The  Product  Backlog  evolves  as  the  product  and  the 
environment  in  which  it  will  be  used  evolves.  The  Product  Backlog  is  dynamic;  it  constantly 
changes  to  identify  what  the  product  needs  to  be  appropriate,  competitive,  and  useful.  If  a 
product exists, its Product Backlog also exists. 

The  Product  Backlog  lists  all  features,  functions,  requirements,  enhancements,  and  fixes  that 
constitute  the  changes to be made to the product in future releases. Product Backlog items have 
the  attributes  of  a  description,  order,  estimate,  and  value. Product Backlog items often include 
test descriptions that will prove its completeness when "Done". 

As  a  product  is  used  and  gains  value,  and  the  marketplace  provides  feedback,  the  Product 
Backlog  becomes  a  larger  and  more  exhaustive  list.  Requirements  never  stop  changing,  so  a 
Product  Backlog  is  a  living  artifact.  Changes  in  business  requirements,  market  conditions,  or 
technology may cause changes in the Product Backlog. 

Multiple  Scrum  Teams  often  work  together  on  the  same  product.  One  Product  Backlog is used 
to  describe  the  upcoming  work  on  the  product.  A  Product  Backlog  attribute  that  groups  items 
may then be employed. 

Product  Backlog  refinement  is  the  act  of  adding  detail,  estimates,  and  order  to  items  in  the 
Product  Backlog.  This  is  an  ongoing  process  in  which the Product Owner and the Development 
Team  collaborate  on  the  details  of  Product  Backlog items. During Product Backlog refinement, 
items  are  reviewed  and  revised.  The  Scrum  Team  decides  how  and  when  refinement  is  done. 
Refinement  usually  consumes  no  more  than  10%  of  the  capacity  of  the  Development  Team. 
However,  Product  Backlog  items  can  be  updated  at  any  time  by  the  Product  Owner  or  at  the 
Product Owner’s discretion. 

Higher  ordered  Product Backlog items are usually clearer and more detailed than lower ordered 

ones.  More  precise  estimates  are  made  based  on  the  greater  clarity  and  increased  detail;  the 
lower  the  order,  the  less  detail.  Product  Backlog  items  that  will  occupy  the  Development Team 
for  the  upcoming  Sprint  are  refined  so  that  any  one  item  can  reasonably  be  "Done"  within  the 
Sprint  time-box.  Product  Backlog  items  that  can  be  "Done"  by  the  Development  Team  within 
one  Sprint are deemed "Ready" for selection in a Sprint Planning. Product Backlog items usually 
acquire this degree of transparency through the above described refining activities. 

The  Development  Team  is  responsible  for  all  estimates.  The  Product  Owner  may  influence  the 
Development  Team  by  helping  it  understand  and  select  trade-offs,  but  the  people  who  will 
perform the work make the final estimate. 

Monitoring Progress Toward Goals 

At  any  point  in  time,  the  total  work  remaining  to  reach  a  goal  can  be  summed.  The  Product 
Owner  tracks  this  total  work  remaining  at  least  every  Sprint  Review.  The  Product  Owner 
compares  this  amount  with  work  remaining  at  previous  Sprint  Reviews  to  assess  progress 
toward  completing  projected  work  by  the  desired  time  for  the  goal.  This  information  is  made 
transparent to all stakeholders. 

Various  projective  practices  upon  trending  have  been  used  to  forecast  progress,  like 
burn-downs,  burn-ups,  or  cumulative  flows.  These  have  proven  useful.  However,  these  do  not 
replace the importance of empiricism. In complex environments, what will happen is unknown. 
Only what has already happened may be used for forward-looking decision-making. 

Sprint Backlog 

The  Sprint  Backlog  is  the  set  of  Product  Backlog  items  selected  for  the  Sprint,  plus  a  plan  for 
delivering  the  product  Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast 
by  the  Development  Team  about  what  functionality  will  be  in  the  next Increment and the work 
needed to deliver that functionality into a "Done" Increment. 

The  Sprint  Backlog  makes  visible  all  the  work  that  the  Development  Team  identifies  as 
necessary  to  meet  the  Sprint  Goal.  To  ensure  continuous  improvement,  it  includes  at least one 
high priority process improvement identified in the previous Retrospective meeting. 

The  Sprint  Backlog  is  a  plan  with  enough  detail  that  changes  in  progress  can  be  understood  in 
the  Daily  Scrum.  The  Development  Team  modifies  the  Sprint  Backlog  throughout  the  Sprint, 
and  the  Sprint  Backlog  emerges  during  the  Sprint.  This  emergence  occurs  as the Development 
Team  works  through  the  plan  and  learns  more  about  the  work  needed  to  achieve  the  Sprint 
Goal. 

As  new  work  is  required,  the  Development  Team  adds  it  to  the  Sprint  Backlog.  As  work  is 
performed  or  completed,  the  estimated  remaining work is updated. When elements of the plan 
are  deemed  unnecessary,  they  are  removed.  Only  the  Development  Team can change its Sprint 
Backlog  during  a  Sprint.  The  Sprint  Backlog  is  a  highly  visible,  real-time  picture  of  the  work 
that  the  Development  Team  plans  to  accomplish  during  the  Sprint,  and  it  belongs  solely  to the 
Development Team. 

Monitoring Sprint Progress 

At  any  point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. 

The  Development  Team  tracks  this  total  work  remaining  at  least  for  every  Daily  Scrum  to 
project  the  likelihood  of  achieving  the  Sprint  Goal. By tracking the remaining work throughout 
the Sprint, the Development Team can manage its progress. 

Increment 

The  Increment  is  the  sum  of  all  the  Product  Backlog  items  completed  during  a  Sprint  and  the 
value  of  the  increments  of  all  previous  Sprints.  At  the  end  of a Sprint, the new Increment must 
be  "Done,"  which  means  it  must  be  in  useable  condition  and  meet the Scrum Team’s definition 
of  "Done".  An  increment  is  a  body  of  inspectable,  done  work  that  supports  empiricism  at  the 
end  of  the  Sprint.  The  increment  is  a  step  toward  a  vision  or  goal.  The  increment  must  be  in 
useable condition regardless of whether the Product Owner decides to release it. 

Artifact Transparency 

Scrum  relies  on  transparency.  Decisions  to  optimize  value  and  control  risk  are  made  based  on 
the  perceived  state  of  the  artifacts.  To  the extent that transparency is complete, these decisions 
have  a  sound  basis.  To  the  extent  that  the  artifacts  are  incompletely  transparent,  these 
decisions can be flawed, value may diminish and risk may increase. 

The  Scrum  Master  must  work  with  the Product Owner, Development Team, and other involved 

parties  to  understand  if  the  artifacts  are  completely transparent. There are practices for coping 
with  incomplete  transparency;  the  Scrum  Master  must  help  everyone  apply  the  most 
appropriate  practices  in  the  absence  of  complete  transparency.  A  Scrum  Master  can  detect 
incomplete  transparency  by  inspecting  the  artifacts,  sensing  patterns,  listening  closely to what 
is being said, and detecting differences between expected and real results. 

The  Scrum  Master’s  job  is  to  work  with  the  Scrum  Team  and  the  organization  to  increase  the 
transparency  of  the  artifacts.  This  work  usually  involves  learning,  convincing,  and  change. 
Transparency doesn’t occur overnight, but is a path. 

Definition of "Done" 

When  a  Product  Backlog  item  or  an  Increment  is  described  as  "Done",  everyone  must 
understand  what  "Done"  means.  Although  this  may  vary  significantly  per  Scrum  Team, 
members  must  have  a  shared  understanding  of  what  it  means  for  work  to  be  complete,  to 
ensure  transparency.  This  is  the  definition  of  "Done"  for  the  Scrum  Team  and  is  used to assess 
when work is complete on the product Increment. 

The  same  definition  guides  the  Development  Team  in  knowing  how  many  Product  Backlog 
items  it  can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments 
of  potentially  releasable  functionality  that  adhere  to  the  Scrum  Team’s  current  definition  of 
"Done". 

Development Teams deliver an Increment of product functionality every Sprint. This Increment 
is  useable,  so  a  Product  Owner  may choose to immediately release it. If the definition of "Done" 
for  an  increment  is  part  of  the  conventions,  standards  or  guidelines  of  the  development 
organization, all Scrum Teams must follow it as a minimum. 

If  "Done"  for  an  increment  is  not  a  convention  of  the  development  organization,  the 
Development  Team  of  the  Scrum  Team  must  define  a  definition  of  "Done"  appropriate  for  the 
product.  If  there  are  multiple  Scrum  Teams  working  on  the  system  or  product  release,  the 
Development Teams on all the Scrum Teams must mutually define the definition of "Done". 

Each  Increment  is  additive  to  all  prior  Increments  and  thoroughly  tested,  ensuring  that  all 
Increments work together. 

As  Scrum  Teams  mature,  it  is  expected  that  their  definitions  of  "Done"  will  expand  to  include 
more  stringent  criteria  for  higher  quality.  New  definitions,  as  used,  may  uncover  work  to  be 
done  in  previously  "Done"  increments.  Any  one  product  or  system  should  have  a  definition  of 
"Done" that is a standard for any work done on it. 

Scrum  processes  address  the  specific  activities  and  flow  of  a  Scrum  project.  In  total there are 
19 processes which are grouped into the following five phases: 

Initiate  -  ​This  phase  includes  the  processes  related  to  initiation  of  a  project:  Create  Project 
Vision,  Identify  Scrum  Master  and  Stakeholder(s),  Form  Scrum  Team,  Develop  Epic(s),  Create 
Prioritized Product Backlog, and Conduct Release Planning.  

Plan  and  Estimate  -​This  phase  consists  of  processes  related  to  planning  and  estimating  tasks, 
which  include  Create  User  Stories,  Approve, Estimate, and Commit User Stories, Create Tasks, 
Estimate Tasks, and Create Sprint Backlog.  

Implement  - This phase is related to the execution of the tasks and activities to create a project's 
product.  These  activities  include  creating  the  various  deliverables,  conducting  Daily  Standup 
Meetings,  and  grooming  (i.e.,  reviewing,  fine-tuning,  and  regularly  updating)  the  Product 
Backlog at regular intervals.  
Review  and  Retrospect  -  This  phase  is  concerned  with  reviewing  the deliverables and the work 
that  has  been  done  and  determining  ways  to  improve  the  practices  and  methods  used  to  do 
project work.  

Release  -  ​This  phase  emphasizes  on  delivering  the  Accepted  Deliverables  to  the  customer  and 
identifying, documenting, and internalizing the lessons learned during the project.  

Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers) 

Prerequisites:  all  items  have  a value estimate, each item is written on a separate note card, full 

team  membership  is  known  and  available  for  planning,  each  team  member  has  a  set  of 
planning game cards: 

The Planning Game Process 

● The  team  goes  through  all  the  items  and  chooses  the  one  which  has  the  lowest  effort. 
Write the number “2” on this card (usually in the bottom right corner). 
● The team looks at the item with the highest value. 
● Each  team  member thinks about how much effort the team will expend to fully complete 
all  the  work  for  the  item.  Comparing  this  work  to  the  work  effort  for the smallest item, 
each  team  member  selects  a  card  that represents this relative effort. For example, if you 
think  that  it  requires  ten  times  the  effort,  you  would  select  the  “20”  card.  It  is  not 
permissible to select two cards. 
 ● Each  team  member  places  their  selected  card,  face  down,  on  the  table.  Once  all  team 
members have done this, turn the cards over. 
● If  all  team  members  show  the  same  value,  then  write  the  value  on  the item and go back 
to  step  three  for  the  next  item.  (Or  if  there  are  no  more  items,  then  the  process  is 
complete.) 
● The  person  with  the  highest  and  the  lowest  value  cards  both  briefly  explain  why  they 
voted  the  way  they  did.  If  there  is  a  Product  Owner  present,  this  person  can  add  any 
clarifications about the item. 
● For  any  given  item,  if  a  person  is  highest  or  lowest  more  than  once,  then  each 
explanation must include new information or reasoning. 
● Once  explanations  are  complete,  the  team  members  collect  their  cards  and  go  back  to 
step three. 

Notes: 

● –  it  is  extremely  important  that the voting for an item continues until all team members 

unanimously  vote  the  same  way  (this  way  team  members  and  outside  stakeholders 
cannot blame any individual for “wrong” estimates) 
● – in Scrum, it is normal for the Product Owner to be present during this process, but not 
to participate in the voting 
● –  in  OpenAgile,  it  is  acceptable  for  people  serving  as  Growth  Facilitators  for  a  team  to 
participate in the voting 
● – voting should not include extensive discussion 
● –  if  more  than  one  person  has  the  lowest  or  highest vote, usually just one person shares 
their reason in order to help the process move quickly 
● –  the  first  few  items  will  often  take  10 or 15 rounds of voting before the team arrives at a 
unanimous vote 
● –  later  on,  items  may  take  just  one  or  two  rounds  of  voting  to  arrive  at  a  unanimous 
decision 
● –  some teams, where trust levels are high, will discard with the use of physical cards and 
just briefly discuss votes 

The  planning game is used at the start of a project with the full list of user stories. In this case, it 
is  reasonable  to  expect  the  team  to  average  two  minutes  per  user  story,  and  an  appropriate 
amount of time needs to be set aside to accommodate going through the whole list. 

The  Planning  Game  is  also  used  any  time  that  there  is  a  change  in  the  list  of  user  stories: 
re-ordering,  adding  or  removing  user  stories,  or  changes  to  a  single  user  story.  When  such  a 
change  happens,  the  team  can  re-estimate  any  user  story  in  the  whole  list.  When  starting  a 
Cycle  or  Sprint  or  Iteration,  all  the  user  stories  in  the  list  should  have  up-to-date  estimates  so 
that estimation work is avoided in the Cycle planning meeting. 
Finally,  the  team  can  decide  to  re-estimate  any  user  stories  at  any  time  for  any  reason. 
However,  it  is  important  for  team  members  to  remember  that  estimation  is  non-value-added 
work and the time spent on it should be minimized. 

Here are 7 agile estimation techniques beyond Planning Poker. 

1. Planning Poker 

All  participants  use  numbered  playing cards and estimate the items. Voting is done anonymous 

and  discussion  is  raised  when  there  are large differences. Voting is repeated till the whole team 
reached  consensus  about  the  accurate  estimation.  Planning  poker  works well when you have to 
estimate  a  relative  small  number  of  items  (max  10)  in  a  small team (5-8 people). Tip: try to keep 
the  voting  between  affordable  numbers.  Maximize  the  highest  card  to  13  points.  More  on 
planning poker via this link.  

2. T-Shirt Sizes 

This is a perfect technique for estimating a large backlog of relative large items. Especially when 
you  have  several  concurrent  scrum  teams  working  on  the  same  product.  Items  are  estimated 
into  t-shirt  sizes:  XS,  S,  M,  L,  XL.  The  decision  about  the  size  is  based  on  an  open  and mutual 
collaborative  discussion.  This  method  is  an  informal  and  quick  way  to  get  an  rough  feeling 
about the total size of your backlog. More about T-shirt size estimation is here. 

3. Dot Voting 

When  you  are  faced with a relative small set of items and in need of a super simple and effective 

technique  to  estimate  you  can  use  Dot  Voting.  This  method  has  originated  form  decision 
making  and  you  can  use  it  for  estimating.  Each  person  gets  a  small  number  of  small  stickers 
and  can  choose  to  vote  for  the  individual  items.  The  more  dots  is  an  indicator  of  a  bigger size. 
Works  well  in  both  small  and  large  group.  You  have  to  limit  the  number  of  estimated  items. 
More on dot voting here. 

4. The Bucket System 

Much  faster  than  planning  poker  is  the  Bucket  System.  This  system  is  a  good alternative when 
estimating  a  large  number  of items with a large group of participants. Create several buckets in 
the  sequence  of  planning  poker.  The  group  estimates  the  items  by  placing  them  in  these 
“buckets”.  Buckets  are  usually  different  sheets  of  brown  paper  where  you  can  place  the  sticky 
note  with  the  item.  But  you  can  also  use  actual  baskets  to  limit  discussion  about  already 
processed items. More on the bucket method here. 
5. Large/Uncertain/Small 

A  very fast method of rough estimating is the Large/Uncertain/Small method. The team is being 
asked  to  place  the  items  in  one  of  these  categories.  The  first  step  is  to  categorize  the  obvious 
items  in  the  two  extreme  categories.  Next  the  group  can  discuss  the  more complex items. This 
is  actually  a  simplification  of  the  bucket  system.  The  system  is especially good to use in smaller 
groups with comparable items. Next you can assign sizes to these 3 categories. 

6. Affinity Mapping 

This  method  is  based  on  finding  similarities in the estimated items. The team is asked to group 

them  together.  Best  way  is  to  execute  this  is  a  visual  way  and  order  them  form small groups to 
large.  It  works  best  with  a  small  group  of  people  and  a  relative small number of items. You can 
assign estimation numbers to the different groups. More information about Affinity Mapping. 

7. Ordering method 

This  is  an  exercise  where  you  get  an  accurate  image  on  the  relative  size  of  items.  This  works 
best  in  a  small  group  of  expert.  All  items  are  placed  in  random  order  on  a  scale  label  ranging 
from  low  to  high.  Every  participant  is  being  asked  to  move  one  item on the scale. Each move is 
just  one  spot  lower  or  one  spot  higher  or  pass  the  turn.  This  continues  till  no  team  member 
want  to  move  items  and  passes  their  turn.  The  ordering  protocol  is  a  method  of  getting  fine 
grained  size  estimates.  Works  best  with  a  relative  small  group  of  people  and a large number of 
items. 

ITERATION PLANNING  

Iteration  Planning  is  an  event  where  all  team  members  determine  how  much  of  the  Team 
Backlog  they  can  commit  to  delivering  during  an  upcoming  Iteration.  The  team  summarizes 
the  work  as  a  set  of  committed  Iteration  Goals.  Teams  plan  by  selecting  Stories  from  the team 
backlog  and  committing  to  execute  a  set of them in the upcoming iteration. The team’s backlog 
has  been  seeded  and partially planned during the Program Increment (PI) Planning meeting. In 
addition,  the  teams  have  feedback—not  only  from  their  prior  iterations  but  from  the  System 
Demo  and  other  teams.  That,  and  the  natural  course  of  changing  fact  patterns,  provides  the 
broader  context  for  iteration  planning.  The  output  of  iteration  planning  is:  The  iteration 
backlog,  consisting  of  the  stories  committed  to  the  iteration,  with  acceptance  criteria,  where 
appropriate  A  statement  of  iteration  goals,  typically  a  sentence  or  two  stating  the  business 
objectives of the iteration A commitment by the team to the work needed to achieve the goals  

Details  

The  purpose  of  iteration  planning  is  to  organize  the  work  and  define  a  realistic  scope  for  the 
iteration.  Each  Agile  Team  agrees  on  a  set  of  Stories  for  the  upcoming  iteration  (the  iteration 
backlog)  and  summarizes  those  stories  into  a  set  of  iteration  goals.  The  iteration  backlog  and 
goals  are  based  on  the  team’s  capacity  and  allow  for  consideration  of  each  story’s  complexity, 
size,  and  dependencies  on  other  stories  and  other  teams.  At  the  end  of  planning,  the  teams 
commit  to  the goal of the iteration and adjust stories as necessary to achieve the larger purpose. 
In return, management does not interfere or adjust the scope of the iteration, allowing the team 
to stay focused on the goals.  

Inputs to Iteration Planning  

In  SAFe,  iteration  planning  is  a  refinement  of the level of detail and an adjustment of the initial 

iteration  plans  created  during  Agile  Release  Train (ART) PI planning. Teams approach iteration 
planning  with  a  pre-elaborated  Team  Backlog.  (They  have  usually  held  a  backlog  refinement 
meeting  during  the  previous  iteration.)  There  are  a  number  of  inputs  to  the planning meeting: 
The  team  and  Program  PI  Objectives,  created  at  PI  planning  The team’s PI plan backlog, which 
consists  of  stories  that were identified during PI planning Additional stories that arise based on 
local  context,  including  items  such  as  defects,  Refactors,  and new stories that have come about 
since  the  planning  session  Feedback  from  the  prior  iteration,  including  any  stories  that  were 
not successfully completed (e.g., did not meet the ‘definition of done’) in that iteration.  

Feedback from the system demo  

Planning  the  Iteration  Prior  to  the  meeting,  the  Product  Owner  (PO)  will  have  prepared  some 
preliminary  iteration  goals,  based  on  the  team’s  progress  in  the Program Increment. Typically, 
the  Product  Owner  starts  the  meeting  by  reviewing  the  proposed  iteration  goals  and  the 
higher-priority  stories  in  the  team  backlog.  During  the  meeting,  the  Agile  team  discusses 
implementation  options,  technical  issues,  Nonfunctional  Requirements  (NFRs),  and 
dependencies,  then  plans  the  iteration.  The  Product  Owner  defines  the  what;  the  team defines 
how  and  how  much.  Throughout  the  meeting,  the  team  elaborates  the  acceptance  criteria  and 
estimates the effort to complete each story.  

Based  on  their  available  capacity  for  the  iteration,  the  team  then  selects  the  candidate  stories. 
Some  break  each story down into tasks and forecast them in hours to confirm that they have the 
capacity  and  skills  to  complete  them.  Once  completed,  the  team  commits  to  the  work  and 
records  the  iteration  backlog  in  a  visible  place,  such  as  a  storyboard,  Kanban  board  or  tooling. 
Planning  is  timeboxed  to  a  maximum  of  four  hours  for  a  two-week  iteration.  Establishing 
Capacity  First,  the  team  quantifies  their  capacity  to  perform  work  in  the  upcoming  iteration. 
Each  team  member  determines  their  availability,  acknowledging  time  off  and  other  potential 
duties.  This  activity  also  takes  into  account  other  standing  commitments—such  as 
maintenance—that  is  distinct  from  new  story  development  (see  the  section  about  capacity 
allocation  in  the  Team  Backlog  article).  Using  their  historical  velocity  as  a  starting  point,  the 
team  subtracts  the  unavailable  time  for  each  team  member  to  determine  the  team’s  actual 
capacity  for  the  iteration.  Story  Analysis  and  Estimating  Once  team  capacity  has  been 
established, the team backlog is reviewed.  

Each  story  is  discussed,  covering  relative  difficulty,  size,  complexity,  technical  challenges,  and 
acceptance  criteria.  Teams  use  Behavior-Driven  Development  (BDD)  to  ensure  a  shared 
understanding  of  each  story’s  specific  behavior.  Finally,  the  team  agrees  to  a  size  estimate  for 
the  story.  There  are  typically  other  types  of  stories  on  the  team  backlog  as  well,  including 
Enablers  that  could  constitute  infrastructure  work,  refactoring,  research  Spikes,  architectural 
improvements,  and  defects.  These  items  are  also  prioritized  and  estimated.  Tasking  Stories 
Some  teams  break each story into tasks. As the tasks are identified, team members discuss each 
one:  who  would  be  the  best  person(s)  to  accomplish  it,  approximately  how  long  it  will  take 
(typically  in  hours),  and  any  dependencies  it  may  have  on  other  tasks  or stories. Once all this is 
understood, a team member takes responsibility for a specific task or tasks.  

As  team  members  commit  to  tasks,  they  reduce  their  individual  iteration  capacity  until  it 
reaches  zero.  Often,  toward  the  end  of  the  session,  some  team  members  will  find  themselves 
overcommitted,  while  others  will  have  some  of their capacity still available. This situation leads 
to  a  further  discussion  among  team  members  to  evenly  distribute  the  work.  While  breaking 
stories  into  tasks is fairly common, it is optional and not mandated in SAFe. It is mostly used by 
beginner  teams  to  learn their velocity and capabilities, and then they become unnecessary, with 
the team planning only with stories.  

Developing Iteration Goals  

Once  the  iteration  backlog  is  understood,  the  team  turns  their  attention to synthesizing one or 
more  iteration  goals  that are based on the team and program PI objectives from the PI planning 
session  and  the  iteration  backlog.  The  closer  this  iteration  is  to  the  PI  planning  session,  the 
more  likely  the  program  objectives  will  remain  unchanged.  Committing  to  Iteration  Goals 
When  the  team’s  collective  capacity  has  been  reached  in  terms  of  committed  stories,  no  more 
stories  are  pulled  from  the  team  backlog.  At  this  point,  the  Product  Owner  and  team  agree  on 
the  final  list  of  stories  that  will  be  selected,  and  they  revisit  and  restate  the iteration goals. The 
entire  team  then  commits to the iteration goals, and the scope of the work remains fixed for the 
duration of the iteration.  

Attendees  

Attendees  of  the  iteration  planning  meeting  include:  The  Product  Owner  The  Scrum  Master, 
who  acts  as  the  facilitator  for  this  meeting  The  Development  Team  Any  other  stakeholders, 
including  representatives  from  different  Agile  teams  or  the  ART,  and  subject  matter  experts 
Agenda  An  example  agenda  for iteration planning follows: Calculate the available team capacity 
for  the  iteration.  Discuss  each  story, elaborate acceptance criteria, and provide estimates using 
story  points.  Planning  stops  once  the  team  runs  out  of  capacity.  Determine  and  agree  on  the 
iteration goals. Everyone commits to the goals.  

Acceptance  criteria  are  developed  through  conversation  and  collaboration  with  the  Product 
Owner  and  other  stakeholders.  Based  on  the  story  estimates,  the  Product  Owner  may  change 
the  ranking  of  the  stories.  Optionally,  the  team  may  break  stories  into  tasks,  estimated  in 
hours,  and  takes  shared  responsibility  for  execution.  Guidelines  Below  are  some  tips  for 
holding  an  iteration  planning  meeting:  Timebox  the  meeting  to  4  hours  or  less  This  planning 
session  is  organized  by  the  team  and  is  for  the  team  A  team  should  avoid  committing  to  work 
that exceeds its historical velocity 

What Is a Burndown Chart? 

A  burndown  chart  is  a  graphic  representation  of  how  quickly  the  team  is  working  through  a 
customer’s  user  stories,  an  agile  tool  that  is  used  to  capture  a  description  of  a  feature  from  an 
end-user  perspective.  The  burndown  chart  shows  the  total  effort  against  the  amount  of  work 
for each iteration. 

The  quantity  of  work  remaining is shown on a vertical axis, while the time that has passed since 

beginning  the  project  is  placed  horizontally  on  the  chart,  which  shows  the  past  and the future. 
The  burndown  chart  is  displayed  so  everyone  on  the  team  can see it and is updated regularly to 
keep it accurate. 

Variations of the Burndown Chart 

There  are  two  variants  that  exist  for  a  burndown  chart.  A  sprint  burndown  is  for  work 
remaining  in  the  iteration.  When  illustrating  the  work  remaining  for  the  entire  project,  the 
chart is called a product burndown. 
How to Read a Burndown Chart 

The  burndown  chart  has  several  points.  There’s  an  x-axis,  which  is  the  project  or  iteration 
timeline.  The  y-axis  is  the  work  that  needs  to  get  done in the project. The story point estimates 
for the work that remains is represented by this axis. 

  The  project  starting  point  is  the  farthest  point  to  the  left of the chart and occurs on day zero of 
the  project  or  iteration.  The  project  end  point  is  farthest  to  the right and marks the final day of 
the project or iteration. 

Ideal Work Remaining Line 

There  is  an  ideal  work  remaining  line,  which  is  a  straight  line  connecting  the  start point to the 
end  point.  It  shows  the  sum  of  the  estimates  for  all  the  tasks  that  need  to be completed. At the 
end  point,  the  ideal  line  crosses  the  x-axis  and  shows  there  is  no  work left to be done. This line 
is based on estimates and therefore not always accurate. 

Actual Work Remaining Line 

Then  there  is  the  actual  work  remaining  line  that  shows  the  actual  work  that  remains  in  the 
project  or  iteration.  At  the  beginning  the  actual  work  remaining  and  the  ideal  work remaining 
are  the  same,  but  as  the  project  or  iteration  progresses  the actual work line will fluctuate above 
and  below  the  ideal  work  line.  Each  day  a  new  point  is  added  to  this  line  until  the  project  or 
iteration is done to make sure it’s as accurate as possible. 

If  the  actual  work  line  is  above  the  ideal  work  line,  it  means  there  is  more  work  left  than 
originally  thought.  In  other  words,  the  project  is  behind  schedule.  However,  if  the actual work 
line  is  below  the  ideal  work  line,  there  is  less  work  left  than  had been predicted and the project 
is ahead of schedule. 

What Are the Benefits of a Burndown Chart? 

● The  obvious  benefit  of  a  burndown  chart  is  that  it  provides  an  updated status report on 
the  progress  of  the  project.  Having  a  visual  representation  of  this  most  important  data 
keeps everyone on the same page. 
● Also,  by  displaying  it  prominently  for  all  to  see,  it  keeps  everyone  involved  and 
encourages  the  team  to  deal  with  issues  before  they  become  problems.  Therefore,  the 
bigger  the  chart,  the  better.  It  should  be  the  focal  point  of  the  workspace,  so  that  it 
cannot help but direct conversation towards the project and its progress. 
 ● The  burndown  chart  is  extremely  helpful,  too,  because  of  its  simplicity.  It’s  a  great way 
to  see  the  velocity  history  of  the  project.  Velocity  is  an  agile  term  that  means  the  total 
effort estimates associated with user stories that were completed during an iteration. 

What Are the Limitations of a Burndown Chart? 

● The burndown chart doesn’t reveal everything. For example, it only shows the number of 
story  points  that  have  been  completed.  The  burndown  chart  doesn’t  show  any  changes, 
for example, in the scope of work as measured by the total points in the backlog. 
● Therefore,  it  can  be  hard  to  tell  if  changes  in  the  burndown  chart  are  because  of  the 
backlog  items  having  been  completed  or  because  of  an  increase  or  decrease  in  story 
points.  Having  a  burnup  chart  can  resolve  this  problem  by  having  a  separate  line in the 
graph for overall backlog size. 
● However,  neither a burndown nor a burnup chart offers any indication of which product 
backlog  items  have  been  completed.  Therefore,  a  burndown  chart  might show progress 
but  not  whether  the  team  is  working  on  the  right  thing.  So,  these  charts  are  a  way  to 
show trends rather than whether the team is delivering the right product back log items. 
● It Relies on Good Estimates 
● Another  issue  with  burndown  charts  concerns  the  accuracy  of  the  ideal  work  line. 
Whether  the  actual  work  line  is  above  or  below  the  ideal  work  line  depends  on  the 
accuracy  of  the  original  time  estimates  for  the  tasks.  Therefore,  if  a  team  is 
overestimating  time  requirements,  progress  will  appear  on  track  if  not  ahead  of 
schedule.  But  if they are underestimating time requirements, it will appear that they are 
behind schedule. 
● There  is  a  way  to  respond  to  this  issue,  and  that’s  by  incorporating  an  efficiency  factor 
into  the  burndown  chart.  Therefore,  after  the  first  iteration  of  a  project,  the  efficiency 
factor is recalculated to allow for more accuracy. 

4 step process for gathering requirements. 

Agile Requirements Levels 

Visioning 

:  This  is  the  initial  step  of  gathering  requirements.  The  goal  is  to  help  identify  all  the  Themes 
and some features desired. This exercise begins to define the scope of what is expected. 
Brainstorming 

:  The  goal  of  this  step  is  to  identify  all  the  features  and  stories  desired.  The  key here is Breadth 
First,  Depth  Later.  So  instead  of  discussing  the  details  of  each feature and story, our main goal 
is to FIND all the features and stories. 

Breakdown 

:  The  goal  of  this  step  to  breakdown  and  slice  the  stories  that  are  still  too  large  (EPICs)  into 
smaller  chunks.  You probably have already done a lot of slicing during brainstorming but as you 
comb  your  backlog,  the  team  will  realize  that  some  stories  are  still  too  large  to  be  completed 
within  an  iteration  (usually  1-4  weeks).  Slicing  stories is an art and I will dedicate an entire blog 
to it! 

Deep Dive 

:  This  is  the  step  everyone  wants  to  jump into right away! Yes, finally let’s talk about the details. 

What  will  be  on  the  screen,  what  are  the  exact  business  rules  and  how  will  we  test  them,  what 
will  the  detailed  process  look like, what are the tasks we need to get done to complete this story. 
Jumping  into  this  level  of  detail  upfront  during  the  initial  phases  is  one  of  the  main  reasons 
contributing to scope creep later during the project. 

The  Deep  Dive  is where the main difference lies between Agile and Waterfall. Traditional teams 

would  gather  this  very  detailed  information  upfront  for  ALL  the  stories  on  the  backlog,  where 
Agile  teams  will  gather  these  details  Just  In  Time  for  the  next  stories,  which  is  one  or  two 
iterations before that story needs to be DONE. 

Here is the list of the most popular software used for Agile project management: 

● monday.com 
● Nifty 
● Kanbanize 
● SpiraTeam 
● ServiceNow 
● Wrike 
● Atlassian Jira 
● Active Collab 
● Agilo for Scrum 
● SpiraTeam 
● Pivotal Tracker 
● VSTS 
● Icescrum 
● Gravity 
 ● SprintGround 
● VersionOne 
● Taiga 

MODULE 3 

"User  stories  are  part  of  an  agile  approach  that  helps  shift  the  focus  from  writing  about 
requirements  to talking about them. All agile user stories include a written sentence or two and, 
more importantly, a series of conversations about the desired functionality" 

Why User Stories? 

Requirements  always  change  as  teams  and  customers  learn  more  about  the  system  as  the 
project  progresses.  It's  not  exactly  realistic  to  expect  project  teams  to  work  off  a  static 
requirements list and then deliver functional software months later. 

With  user  story  approach,  we  replace  big  upfront  design  with  a  "just  enough"  approach.  User 
stories  reduce  the  time  spent  on  writing  exhaustive  documentation  by  emphasizing 
customer-centric  conversations.  Consequently,  user  stories  allow  teams  to  deliver  quality 
software  more  quickly,  which  is  what  customers  prefer.  There  are  quite  a  few  benefits  for 
adopting user story approach in agile development such as: 

● The  simple  and  consistent  format  saves  time  when  capturing  and  prioritizing 
requirements  while  remaining  versatile  enough  to  be  used  on  large  and  small  features 
alike. 
● Keep  yourself  expressing  business  value  by  delivering  a  product  that  the  client  really 
needs 
● Avoid  introducing  detail  too  early  that  would  prevent  design  options  and 
inappropriately lock developers into one solution. 
● Avoid the appearance of false completeness and clarity 
● Get to small enough chunks that invite negotiation and movement in the backlog 
● Leave the technical functions to the architect, developers, testers, and so on 

Basic Concepts of User Story 

A  user  story  is  a  lightweight  method  for  quickly  capturing  the  "who",  "what"  and  "why"  of  a 
product  requirement.  In  simple  terms,  user  stories  are  stated  ideas  of  requirements  that 
express  what  users  need.  User  stories  are  brief,  with  each  element often containing fewer than 
10  or  15  words  each.  User  stories  are  "to-do"  lists  that  help  you  determine  the  steps  along  the 
project's  path.  They  help  ensure  that  your  process,  as  well  as  the  resulting  product,  will  meet 
your requirements. 

A user story is defined incrementally, in three stages: 

● The brief description of the need 

● The  conversations  that  happen  during  backlog  grooming  and  iteration  planning  to 
solidify the details 
● The tests that confirm the story's satisfactory completion 

And these, although, are known as the 3C's - Card, Conversation and Confirmation. We will talk 
more about this later on in this user story guide. 

User Stories - INVEST 

The  acronym  INVEST helps to remember a widely accepted set of criteria, or checklist, to assess 

the  quality  of  a  user  story.  If  the  story  fails  to  meet  one  of  these  criteria,  the team may want to 
reword  it,  or  even  consider  a  rewrite  (which  often  translates  into  physically  tearing  up  the  old 
story card and writing a new one). 

A good user story should be - INVEST: 

● Independent:  ​Should  be  self-contained  in  a  way  that  allows  to  be  released  without 
depending on one another. 
● Negotiable:  ​Only capture the essence of user's need, leaving room for conversation. User 
story should not be written like contract. 
● Valuable:​ Delivers value to end user. 
● Estimable:  ​User  stories  have  to  able  to be estimated so it can be properly prioritized and 
fit into sprints. 
● Small:  A  user  story  is  a  small chunk of work that allows it to be completed in about 3 to 4 
days. 
● Testable:​ A user story has to be confirmed via pre-written acceptance criteria. 
How to Write User Stories? 

When  getting  started  with  writing  user  stories,  a  template  can  help  ensure  that  you  don't 
inadvertently start writing technical tasks: 

User Story Template 

User stories only capture the essential elements of a requirement: 

● Who it is for? 
● What it expects from the system? 
● Why it is important (optional?)? 

Detailing User Stories with 3Cs (Card, Conversation and Confirmation) 

Ron  Jeffries, another of the creators of XP, described what has become our favorite way to think 
about  user  stories.  A  User  Story  has  three  primary  components,  each  of  which  begin  with  the 
letter  'C':  Card,  Conversation,  and  Confirmation  to  describe  the  three  elements  of a user story. 
Where: 

Card 

Card  represents  2-3  sentences  used  to  describe  the  intent  of the story that can be considered as 
an  invitation  to  conversation.  The  card  serves  as  a memorable token, which summarizes intent 
and represents a more detailed requirement, whose details remain to be determined. 

You  don't  have  to  have  all  of  the  Product  Backlog  Items  written  out  perfectly  "up  front", before 
you  bring them to the team. It acknowledges that the customer and the team will be discovering 
the underlying business/system needed as they are working on it. This discovery occurs through 
conversation  and  collaboration  around  user  stories.  The  Card  is  usually  follows  the  format 
similar to the one below: 

As a (role) of the product, I can (do action) so that I can obtain (some benefits / value) 

Note: 

The  written  text,  the  invitation  to  a  conversation,  must address the "who (role)", "what (action)" 

and "why (benefits)" of the story. 

Conversation 
Conversation  represents  a discussion between the target users, team, product owner, and other 
stakeholders,  which  is  necessary  to  determine  the  more  detailed  behavior  required  to 
implement  the  intent.  In  other  words,  the  card  also  represents  a  "promise  for  a  conversation" 
about the intent. 

The  collaborative  conversation  facilitated  by  the  Product Owner which involves all stakeholders 

and the team. 

The  conversation  is  where  the  real  value  of  the  story  lies  and  the  written  Card  should  be 
adjusted to reflect the current shared understanding of this conversation. 

This  conversation  is  mostly  verbal  but  most  often  supported  by  documentation  and  ideally 
automated tests of various sorts (e.g. Acceptance Tests). 

Confirmation 

Confirmation  represents  the  Acceptance  Test, which is how the customer or product owner will 

confirm  that  the  story  has  been  implemented  to  their  satisfaction.  In  other  words, 
Confirmation  represents  the  conditions  of  satisfaction  that  will  be  applied  to  determine 
whether or not the story fulfills the intent as well as the more detailed requirements. 

The Product Owner must confirm that the story is complete before it can be considered "done" 

The  team  and  the  Product  Owner  check  the  "doneness"  of  each  story  in  light  of  the  Team's 
current definition of "done" 

Specific  acceptance  criteria  that  is  different  from  the  current  definition  of  "done"  can  be 
established  for  individual  stories,  but  the  current  criteria  must  be  well  understood  and  agreed 
to by the Team. All associated acceptance tests should be in a passing state. 

We list the major steps for identifying user stories as following: 

● Through  the  discussions  with  users,  we  listen  to  and  understand  their  problems  and 
needs 
● And then, write down their needs as user stories at the same time. 
● These user stories will become the source of requirements. 
● The  details  could  be  subsequently  filled  just-in-time,  providing  the  team  with  a 
"just-enough" requirement references throughout the project development process. 

Lifecycle of a User Story 

In a broad sense, there are six main states for each user story throughout a software project: 

Pending 

Through  the  communication  between  user  and  project  team,  user  stories  are  found.  At  this 
state,  the  user  stories  have  nothing  more  than  a  short  description  of  user's  need.  There  is  no 
detailed  discussion  of  requirements,  no  system  logic  and  no  screen design yet. In fact, the only 
purpose  of  user  story,  for  now,  is  just  for  reminding  all  parties  for a future discussion of user's 
request  written  in  this  user  story  (card). It is possible that the user story will be discarded in the 
future. 

To-do 

Through  a  discussion  between  different  stakeholders,  the  user  stories  to  be  addressed  in  the 
next  few  weeks  are  decided,  and  are  put  into  a  time-box  called  a  sprint.  Such  user  stories  are 
said to be in the to-do state. No detailed discussion has yet been carried out in this state. 

Discussing 

When  a  user  story  is  in the Discussing state, the end user will communicate to the development 

team  in  confirming  the  requirements  as  well  as  to  define  the acceptance criteria. Development 
team  will  write  down  the  requirements  or  any  decisions  as  conversation  notes.  UX  specialist 
may  create  wireframes  or  storyboards  to  let  user  preview  the  proposed  features  in  visual 
mock-ups, and to feel it. This process is known as user experience design (UX design). 

Developing 

After  the  requirements  are  clarified,  the  development  team  will  design  and  implement  the 
features to fulfill user's requests. 

Confirming 

Upon  the  development  team  has  implemented  a  user  story,  the  user  story  will be confirmed by 
the  end  user.  He/she  will  be  given  access  to  the  testing  environment  or  a  semi-complete 
software  product  (sometimes  known  as  an  alpha  version)  for  confirming  the  feature. 
Confirmation  will  be  performed  based  on  the  confirmation  items  written  when  detailing  the 
user story. Until the confirmation is done, the user story is said to be in the Confirming state. 

Finished 

Finally,  the  feature  is  confirmed  to  be  done,  the  user  story  is  considered  in  the  Finished  state. 
Typically, this is the end of the user story. If user has a new requirement, either it is about a new 
feature,  or  it  is  an  enhancement  of  the  finished  user  story,  the  team  would  create  a  new  user 
story for the next iteration. 

AGILE DESIGN PRINCIPLES 

Single Responsibility Principle: SRP 

A class should have only one reason to change. 

In  the  SRP  context,  responsibility  can  be  defined  as  "a  reason  to  change".  When  the 
requirements  of  the  project  modify,  the  modifications  will  be  visible  through  the  alteration  of 
the  responsibilities  of  the  classes.  If  a  class  has  several  responsibilities,  then,  it  will  have  more 
reasons  to  change.  Having  more  coupled  responsibilities,  the  modifications  on a responsibility 
will  imply  modifications  on  the  other  responsibilities  of  the  class.  This  correlation  leads  to  a 
fragile design. 

Fragility  means  that  a  modification  of  the  system  leads  to  a break in design, in places that have 
no conceptual connection to the part which has been modified. 

Open Closed Principle: OCP 

Software  entities  (classes,  modules,  functions,  etc.)  should  be  open  for  extension,  but  closed 
for modification. 

When  a  single  modification  on  a  software  module  results  in  the  necessity  to  modify  a  series of 
other  modules,  the  design  suffers  from  rigidity.  The  OCP  principle  advocates  design 
refactoring  so  that  further  modifications  of the same type will no longer produce modifications 
on the existing code, which already functions, instead it will only require adding new modules. 

A software module observing the Open-Closed principle has two main characteristics: 

"Open for extensions." 

This  means  that  the  behaviour  of  the  code  can  be  extended.  When  the  requirements  of  the 
project  are  modified,  the  code  can  be  extended  by  implementing  the  new  requirements, 
meaning that one can modify the behaviour of the already existing module. 

"Closed for modifications." 

The  implementation  of  the  new  requirements  does  not  need  modifications  on  the  already 
existing code. 

Abstraction  is  the method which allows the modification of the behaviour of a software module, 

without  modifying  its  already existing code. In C++, Java or any other object oriented language, 
it  is  possible  to  create  an  abstraction  which offers a fixed interface and an unlimited number of 
implementations, namely different behaviours  

The Liskov Substitution Principle (LSP) 

Subtypes must be substitutable for their base types. 

In  languages  such  as  C++  or  Java,  the  main  mechanism  through  which  abstraction  and 
polymorphism  is  done is inheritance. In order to create a correct inheritance hierarchy we must 
make  sure  that  the  derived  classes  extend,  without  replacing,  the  functionality  of  the  base 
classes.  In  other  words,  the  functions  using  pointers  or references to the base classes should be 
able  to  use  instances  of  the  derived  classes  without  being  aware  of  this.  Contrary,  the  new 
classes  may  produce  undesired  outcomes  when  they  are  used  in  the  entities  of  the  already 
existing  program.  The  importance  of  the  LSP  principle  becomes  obvious  the  moment  it  is 
violated. 

Dependency Inversion Principle (DIP) 

A.  High-level  modules  should  not  depend  on  low-level  modules.  Both  should  depend  on 
abstract modules. 

B. Abstractions should not depend upon details. Details should depend upon abstractions. 

This  principle  enunciates  the  fact  that  the  high-level  modules  must be independent of those on 
lower  levels.  This  decoupling  is  done  by  introducing  an  abstraction  level  between  the  classes 
forming  a  high  hierarchy  level  and  those  forming  lower  hierarchy  levels.  In  addition,  the 
principle  states  that  the  abstraction  should  not  depend  upon  details,  but  the  details  should 
depend  upon  the  abstraction.  This  principle  is  very  important  for  the  reusing  of  software 
components.  Moreover,  the  correct  implementation  of  this  principle  makes  it  much  easier  to 
maintain the code. 

The Interface Segregation Principle (ISP) 

Clients should not depend on interfaces they do not use. 

This  principle  stresses  the  fact  that  when  an  interface  is  being  defined,  one  must  be  careful  to 
put  only  those  methods  which  are  specific  to  the  client  in  the  interface.  If  in  an  interface  one 
adds  methods  which  do  not  belong  there,  then  the classes implementing the interface will have 
to  implement  those  methods,  too.  For  instance,  if  we  consider  the  interface  Employee,  which 
has  the  method  Eat, then all the classes implementing this interface will also have to implement 
the  Eat  method.  However,  what  happens  if  the  Employee  is  a  robot?  Interfaces  containing 
unspecific methods are called "polluted" or "fat" interfaces. 

CODE REFACTORING 

Basically,  code  refactoring  is  the  process  of  changing  a  program’s  source  code  without 
modifying  its  external  functional  behavior,  in  order  to  improve  some  of  the  nonfunctional 
attributes  of  the  software.  In  other  words,  code  refactoring  is  the  process  of  clarifying  and 
simplifying  the  design  of  existing  code,  without  changing  its  behavior.  Nowadays,  agile 
software  development  is  literally  a  must  and  agile  teams  are  maintaining  and  extending  their 
code  a  lot  from  iteration  to  iteration,  and  without  continuous  refactoring,  this  is  hard  to  do. 
This  is  because  un-refactored  code  tends  to  rot:  unhealthy  dependencies  between  classes  or 
packages,  bad  allocation  of  class  responsibilities,  way  too  many  responsibilities  per  method  or 
class,  duplicated  code,  and  many  other  varieties  of  confusion  and  clutter.  So,  the  advantages 
include  improved  code  readability  and  reduced  complexity;  these  can  improve  source-code 
maintainability and create a more expressive internal architecture. 

Some Tips for Doing Code Refactoring Techniques Right 

● Code  refactoring  should  be  done  as  a  series  of  small  changes,  each  of  which  makes  the 
existing  code  slightly  better  while  still  leaving  the  program  in  working order. Don’t mix 
a whole bunch of refactorings into one big change. 
● When  you  do  refactoring,  you  should  definitely  do  it  using  TDD  and  CI. Without being 
able  to  run  those  tests  after  each  little  step  in  a  refactoring,  you  create  a  risk  of 
introducing bugs. 
● The code should become cleaner. 
● New  functionality  should  not  be  created during refactoring. Do not mix refactoring and 
direct  development  of  new  features.  Try  to  separate  these  processes  at  least  within  the 
confines of individual commits. 

Benefits of Code Refactoring  

Seeing the Whole Picture 

If  you  have  one  main  method  that  handles  all  of  the  functionality,  it’s  most  likely  way  too  long 
and  incredibly  complex.  But  if  it’s  broken  down  into  parts,  it’s  easy  to  see  what  is  really  being 
done. 

Make It Readable for Your Team 

Make it easy to understand for your peers, don’t write it for yourself, think on the long-term. 

Maintainability 

Integration  of  updates  and  upgrades  is  a  continuous  process  that  is unavoidable and should be 
welcomed.  When  the  codebase  is  unorganized  and  built  on  weak  foundation,  developers  are 
often  hesitant  to  make  changes.  But  with  code  refactoring,  organized code, the product will be 
built on a clean foundation and will be ready for future updates. 

Efficiency 

Code  refactoring  may  be  considered  as  investment,  but  it  gets  good  results.  You  reduce  the 
effort required for future changes to the code, either by you or other developers, thus improving 
efficiency. 

Reduce Complexity 

Make it easier for you and your team to work on the project. 

List of Main Code Refactoring Techniques 

Red-Green Refactoring 

Let's  start  by  briefly  talking  about  the  very  popular  red-green  code  refactoring  technique. 
Red-green  refactor  is  the Agile engineering pattern which underpins Test Driven Development. 
Characterized  by  a  “test-first”  approach to design and implementation, this lays the foundation 
for  all  forms  of  refactoring.  You  incorporate  refactoring  into  the  test  driven development cycle 
by  starting  with  a  failing  “red”  test,  writing  the  simplest  code  possible  to  get  the  test  to  pass 
“green,”  and  finally  work on improving and enhancing your code while keeping the test “green.” 
This  approach  is  about  how  one  can  seamlessly  integrate  refactoring  into  your  overall 
development  process  and  work towards keeping code clean. There are two distinct parts to this: 
writing  code  that  adds  a  new  function  to  your  system,  and  improving  the  code  that  does  this 
function.  The  important  thing  is  to  remember  to  not  do  both  at  the  same  time  during  the 
workflow.  
Preparatory Refactoring  

As  a  developer,  there  are  things  you  can  do  to  your  codebase  to  make  the  building of your next 
feature  a  little  more  painless.  Martin  Fowler  calls  this  preparatory  refactoring.  This  again  can 
be  executed  using  the  red-green  technique  described  above.  Preparatory  refactoring  can  also 
involve  paying  down  technical  debt  that  was  accumulated  during  the  earlier  phases  of  feature 
development.  Even  though  the  end-users  may  not  see  eye  to  eye  with  the  engineering  team on 
such efforts, the developers almost always appreciate the value of a good refactoring exercise. 

Branching by Abstraction Refactoring 

Abstraction  has  its  own  group  of  refactoring  techniques,  primarily  associated  with  moving 
functionality  along  the  class  inheritance  hierarchy,  creating  new  classes  and  interfaces,  and 
replacing inheritance with delegation and vice versa. For example: Pull up field, pull up method, 
pull  up  constructor  body,  push  down  field,  push  down  method,  extract  subclass,  extract 
superclass,  extract  interface,  collapse  hierarchy,  form  template  method,  replace  inheritance 
with delegation, replace delegation with Inheritance, etc. 

There  are  two  types  of  refactoring  efforts  that  are  classified  based  on  scope  and  complexity. 
Branching  by  abstraction  is  a  technique  that  some  of  the  teams  use  to  take  on  large  scale 
refactoring.  The  basic  idea  is to build an abstraction layer that wraps the part of the system that 
is to be refactored and the counterpart that is eventually going to replace it. For example:  

● encapsulate field – force code to access the field with getter and setter methods, 
● generalize  type  –  create  more  general  types  to  allow  for  more  code  sharing,  replace 
type-checking code with state, replace conditional with polymorphism, etc.  

Composing Methods Refactoring 

Much  of  refactoring  is  devoted to correctly composing methods. In most cases, excessively long 

methods  are  the root of all evil. The vagaries of code inside these methods conceal the execution 
logic  and  make  the  method  extremely  hard  to  understand  and even harder to change. The code 
refactoring  techniques  in  this  group  streamline  methods,  remove  code  duplication.  Examples 
can  be:  extract  method,  inline method, extract variable, inline Temp, replace Temp with Query, 
split temporary variable, remove assignments to parameters, etc. 

Moving Features Between Objects Refactoring 

These  code  refactoring  techniques  show  how  to  safely  move  functionality  between  classes, 
create  new  classes,  and  hide  implementation  details  from  public  access.  For  example:  move 
method,  move  field,  extract  class,  inline  class,  hide  delegate,  remove  middle  man,  introduce 
foreign method, introduce local extension, etc. 

Simplifying Conditional Expressions Refactoring  

Conditionals  tend  to  get  more  and  more  complicated  in  their  logic  over  time, and there are yet 
more  techniques  to  combat  this  as  well.  For  example:  consolidate  conditional  expression, 
consolidate  duplicate  conditional  fragments,  decompose  conditional,  replace  conditional  with 
polymorphism, remove control flag, replace nested conditional with guard clauses,etc. 

Simplifying Method Calls Refactoring 

These  techniques  make  method  calls  simpler  and  easier  to  understand.  This  simplifies  the 
interfaces  for  interaction  between  classes.  For  example:  add  parameter,  remove  parameter, 
rename  method,  separate  query  from  modifier,  parameterize  Method,  introduce  parameter 
object,  preserve whole object, remove setting method, replace parameter with explicit methods, 
replace parameter with method call, etc. 

Breaking Code Apart Into More Logical Pieces Refactoring 

Componentization  breaks  code  down  into  reusable  semantic  units  that  present  clear, 
well-defined,  simple-to-use  interfaces.  For  example:  extract  class  moves  part  of  the  code  from 
an  existing  class  into  a  new  class,  extract  method,  to  turn  part  of  a  larger  method  into  a  new 
method.  By  breaking  down  code  in  smaller  pieces, it is more easily understandable. This is also 
applicable to functions. 

User Interface Refactoring 

A  simple  change  to  the  UI  retains  its  semantics,  for  example:  align  entry  field,  apply  common 
button size, apply font, indicate format, reword in active voice and increase color contrast, etc. 

 
 

MODULE 4  

Nine Principles for testing on Agile teams: 

1. Testing Moves the Project Forward. 

The  adversarial  relationship  that  some  organizations  foster  between  testers  and  developers 
must be replaced with a spirit of collaboration. 

2. Testing is NOT a Phase! 

Agile  teams  test  continuously.  Continuous  testing  is  the  only  way  to  ensure  continuous 
progress. 

3. Everyone Tests. 

On  traditional  projects,  the  independent  testers  are  responsible  for  all  test  activities.  In  Agile, 
getting  the  testing  done  is  the  responsibility  of  the  whole  team.  Testers  execute  tests,  and 
developers do too. 

4. Shortening Feedback Loops 

● Feedback  loop  is  the  time  between  when  a  programmer  writes  a  line  of  code  and  when 
someone/something executes that code and provides information about how it behaves. 
● Short  feedback  loops  increase  Agility.  On  Agile  projects  the  software  is  ready  to  test 
almost from the beginning. 
● Agile projects favor automated tests because of the rapid feedback they provide. 
 ● Manual  testing,  particularly  manual  exploratory  testing,  is  still  important.  However, 
Agile  teams  typically  find  that  the  fast  feedback  afforded  by  automated  regression  is  a 
key to detecting problems quickly, thus reducing risk and rework. 

5. Keep the Code Clean. 

This principle is an example of the discipline that Agile teams have. 

6. Lightweight Documentation. 

Instead of writing verbose, comprehensive test documentation, Agile testers: 

● Use reusable checklists to suggest tests 

● Focus on the essence of the test rather than the incidental details 
● Use lightweight documentation styles/tools 
● Capturing test ideas in charters for Exploratory Testing 
● Leverage documents for multiple purpose 

7. Using One Test Artifact for Manual and Automated Tests. 

The  test  could  be  executed  manually,  but  more  importantly  that  same  test  artifact  becomes  an 
automated test. 

8. “Done Done,” Not Just Done. 

In traditional environments that have a strict division between development and test, 

● It  is  typical  for  the  developers  to  say  they  are  “done”  with  a  feature  when  they  have 
implemented it, but before it is tested. 
● Agile  teams  don’t  count  something  as  “done,”  and  ready  to  be  accepted  by  the  Product 
Owner or Customer until it has been implemented and tested. 

9. Test-Driven Development. 

In  traditional  environments,  the  requirements  and  design  come  first, and the tests follow. And 

executing those tests happens at the end of the project. This is a “testlast” approach. 

However,  tests  provide  concrete  examples  of  what  it  means  for  the  emerging  software to meet 
the  requirements.  Defining  the  tests  with  the  requirements,  rather  than  after, and using those 
tests  to  drive  the  development  effort,  gives  us  much  more  clear  done  criteria  and  shared  focus 
on the goal. This test-first approach can be seen in the TDD and ATDD practices. 

Six Practices: 

● 1. Automated Unit / Integration tests. 

● 2. Test Driven Development (TDD). 
● 3. Automated System-Level Regression Tests. 
● 4.  Acceptance  Test  Driven  Development  (ATDD  =  Discuss  ->  Distill  ->  Develop  -> 
Demonstrate). 
● 5. Exploratory testing. 
● 6.  Version  tests  WITH  code  (Source  control  repository  includes  source  code,  unit  tests, 
and system tests). 

What Agile Alliance Is and What it Does 

Agile  Alliance  is  a  nonprofit  organization  committed  to  supporting  people  who  explore  and 
apply  Agile  values, principles, and practices to make building software solutions more effective, 
humane,  and  sustainable.  The  membership  consists  of  a  thriving  and  diverse  community  of 
nearly  70,000  people  who  share  those interests. Its membership and staff enable the Alliance to 
provide  a  global  set  of  resources,  events,  and  communities  to  help  people  reach  their  full 
potential and deliver innovative solutions like never before. 

The  overall  goal  of  each  Agile  method  is  to  adapt  to  change  and  deliver  working  software  as 
quickly  as  possible.  However,  each  methodology  has  slight  variations  in  the  way  it  defines  the 
phases  of  software  development.  Furthermore,  even  though  the  goal  is  the  same,  each  team’s 
process  flow  may  vary  depending  on  the  specific  project  or  situation.  As  an  example,  the  full 
Agile  software  development  lifecycle  includes  the  concept,  inception,  construction,  release, 
production, and retirement phases. 

OTHER ALLIANCES- ScrumAlliance, Scrum.org 

The Agile Process Flow 

Concept - Projects are envisioned and prioritized 

Inception  -  Team  members  are identified, funding is put in place, and initial environments and 

requirements are discussed 

Iteration/Construction  -  The  development  team  works  to  deliver  working  software  based  on 
iteration requirements and feedback 
Release  -  QA  (Quality  Assurance)  testing,  internal  and  external  training,  documentation 
development, and final release of the iteration into production 

Production - Ongoing support of the software 

Retirement - End-of-life activities, including customer notification and migration 

MARKET SCENARIO-Changes caused by the transition to agile- also on page 92 

Measures of success 

In traditional development the main measure of success for a project is usually on time delivery, 
but  in  Agile  this  changes  to  working  code.  This  is  a  fundamental  difference  in  measuring 
success.  Instead  of  time  driven,  the  project  will  be  quality  driven.  Of  course  this has its impact 
on  testing.  When  working  code  is  the  measure  of  success,  we  need  to  put  more  effort  in 
providing working code. The only way for the team to find out that it is working is by testing. 

In  traditional  development  the  focus  for  the  different  disciplines  (such  as  business  analysts, 
developers  and  testers)  is  on  different  aspects.  In  Agile  the  complete  cross  functional  team 
needs  to  have  its  main  focus  on  quality.  To  make  this  happen,  it  is  important  to  spread  the 
knowledge of testing across the whole team. This can be achieved by: 

● using  pairing  to  pair  testers  with  people  in  other  roles  to  facilitate  implicit  knowledge 
sharing; 
● providing  basic  test  training  for  the  team members to explicitly focus on testing aspects 
of their roles. 

Both  of  these  methods  can  be  executed  by  the  tester  in  the  team,  but  the  latter  of  the  two  can 
also  be  executed  by  people  outside  the  team.  Testers  need  to  communicate  with  all  different 
roles in a project and help them to understand and apply testing in their context. 

Management culture 

Another  important  aspect  that  needs  to  change  is  the  management  culture.  Where  the 
keywords  in  traditional  development  are  command  and  control,  the  culture  needs  to  shift 
towards  collaborative  leadership  and  empowerment  of  teams.  The  impact  on  testing  as  a  craft 
seems  minimal,  but  the  impact  on  the  traditional  test  functions,  such  as  test  managers  and 
testers, is large. 

Test  managers  used  to  be  responsible  for  test  strategy,  product  risk  analysis,  test  plans,  test 
estimation, resourcing, etc. But how will this work in Agile/SCRUM? 

● Planning and estimation are a team responsibility. 

● Detailed product risk analysis upfront is not possible. 
● Teams need a degree of freedom, so extensive strategy and plans are uncalled for. 

In  short,  the  role  of  test  management  changes.  The  human  resources  aspect of management is 
more  important. How to get the right tester in the right team and keep the testing knowledge of 
the  testers  up-to-date?  This  is  done  by  knowing  the  testers  and  their  needs.  Test  management 
needs  to  find  ways  to  get  the  necessary  information  out  of  the  different  (SCRUM)  teams  in 
order to have a bird’s eye view on the testing process. 

Keep  in  mind  that  a  lot  of  the  previous  management  responsibility  shifts  to  the  teams.  This 
requires  a  high  rate  of  trust  in  the  people  and  keeping  away  from  micro  management.  So 
management  needs  to  let  go  some  of  the  control  and  the  people  in  the  teams  have  more 
responsibilities  and  need  to  deal  with  this.  Mind  that  not  everyone  will  feel  comfortable  with 
this,  so  make  sure  to  pick  the  right  people  for  the  different  roles  in  the  team.  Next  to  that: not 
every team needs the same type of tester. 

● Requirements and design 

The  change  in  requirements  and  design  is  very  big  and  testing needs to find a way to cope with 
this.  Where  we  had  big  upfront  design,  we  now  have  continuously  changing, emergent, just in 
time documents. This impact on testing is felt at management level and at engineering level. 

In  Agile,  test  management  cannot  identify  the  detailed  risks,  since  there  only  is  a  high  level, 
global  set  of  requirements.  To  retain  a  risk  based  testing  approach,  we  need  different  levels  of 
product  risk  analysis,  abstract  up  front  and  more  detailed  in  the  teams  when  more  detail  is 
known.  So  (test)management  should  be  able  to  do  a  high  level  risk  assessment  at  product 
backlog level, where the team will do detailed risk assessments at the sprint backlog level. 

One  of  the  main  complaints  by  traditional  trained  testers  in an Agile environment is the lack of 
upfront  requirements  and  designs  to  use  as  a  basis  for  their  testing.  Test cases need to emerge 
from  discussions  at  the  grooming  or  planning  session.  Testers  need  to  start  creating test cases 
based  on  these  discussions  before  the  requirements  and  designs  are  properly  documented.  By 
having  testers  and  designers  review  each  other’s  products  you  have  quality  control  early  in  the 
process.  Test  cases  and  designs  prove  to  have  a  better  match  and  any  differences  can  be 
discussed with the product owner. 
Note  that  a  good  product  owner  is  indispensable  for  Agile  projects.  Only  by  good  product 
ownership, the right product gets build. 

Coding and implementation 

Everybody  is  aware  of  the  different  phases  in  a  traditional  project.  Testing  takes  place  after 
coding,  which  in  its  place  is  after  design.  A  good  practice  in  Agile/SCRUM  is  the  use  of  test 
driven  development  (TDD).  Coding and testing then go hand in hand. This increases the quality 
and  maintainability of the code. The shift to TDD is not always that easy. Developers often don’t 
like  to  write  unit  tests  and  did  not  receive  proper  training  in  how  to  do  right TDD. When used 
incorrectly,  TDD  will  take  a  lot  of  time  and  have  no  or  little  benefits.  Testing  can  support once 
again by pairing to support the developers with applying white box testing techniques. 

The  short  development  cycles  and  the  incremental  approach  require  a lot of regression testing. 
Since  regression  testing  takes  place  in  every  sprint,  test  automation  will  save  a  lot of time. The 
impact  is that people with test automation skills are needed it the team and that we need to plan 
for  the  automation.  If  the  testers  are  not  able  to  automate  the  tests  themselves,  they  at  least 
need to know what should be automated and communicate this with the automation specialist. 

Overall impact on testing 

Basically,  we  still  need  to  test.  The  craft  of  testing  is  still  in  place  and  we  must  not  forget what 
we learned in the past. But we need to adjust and adapt to our new context: Agile. The quick and 
changing  world  of  Agile  development  requires  a  more  pragmatic  approach  to  testing.  No large 
upfront  planning  and  documenting,  but  small  pieces  of  functionality.  Pieces  that  are 
manageable by the teams. Testing goes beyond the tester; it is part of the complete team. 

Automation  has  become  an  essential  part  of  testing  to  keep  up  with  the  development  pace  in 
Agile.  This  requires  the  testers  to  have  more  technical  knowledge  and  better  communication 
skills.  An  early  start  with  automation,  usually  results  in  a  better  maintainable  product,  so 
enough reason to automate! 

Last  but  not  least,  it’s  all  about  people!  Investing  in  people  and  skills  is  needed  to perform well 
in  an  Agile  context. Provide training in testing for all team members and don’t forget to provide 
training in other disciplines for the testers as well. 

Fundamental Points for Agile Test Automation 

So  we  need  to  consider  certain  fundamental  points  here  when  it comes to evaluating the use of 
agile  methodologies  with  respect  to  the  Automation  Testing  methods  and techniques. Thus we 
need  to  consider  some  fundamental  points  like  time  taken  for  design  and coding, validation of 
the  designed  scripts  with  the  existing  test  data  and  the  adoption  of  the  same  for  testing 
(whether  the  tests  are  of  functional  or  regression  purposes) So the real fact of all these events is 
that  in  order  to  perform  all  these  facts, we need to ensure that a considerable amount of time is 
required  for  these  tasks  and  in  an  agile  environment  where  an  average  sprint  takes  an average 
1-2  weeks  to  complete  and  thus  it  is  obviously  too  difficult  to  contemplate  affording  so  much 
time for automating scripts in such a way. 

Another  significant  factor  remains  here  that  the  type  of  changes  in  requirements  which  come 
into  picture  when  the  agile  methodology  is  at  play.  The  agile  methodology  by  its  own  very 
definition  is  a  sort  of  technique  which is very helpful for responding to quick customer induced 
change  requirements  and  which  thus  lends  itself  well  to  frequent  changes  during  the  overall 
development of the application. 

In  contrast,  automation  testing  is  very  useful  when  it  comes  to  the  more  stable  and  less 
frequent  types  of  requirements.  Thus  by  definition  automation  testing  does not lend itself well 
to  various  types  of  frequent  changes  in  requirements  which  comes  alongside  the  adoption  of 
any agile methodologies. 

AUTOMATION TESTING PROCESS 

Test Plan 

A  test  plan  is  created  for  each  release  and  needs  to  be  updated  after  every  release.  The  main 
purpose  of  creating  the  test  plan  before  the  start  of  a  release  is  to  outline  the  scope,  test 
approach,  entry  and  exit  criteria  for  the  release.  The  exit  criteria  becomes  the  acceptance 
criteria for the release to be pushed to UAT and approved by the Product Owner. 

Sprint Planning 

The  next  phase  of testing activity starts in sprint planning. The team sits together to discuss the 

efforts  involved  across  the  planned  user  stories  in  a  sprint  and  any  dependencies  involved  in 
terms  of  development  or  testing.  The  team  coordinate  together to achieve the required velocity 
of  the  sprint.  Efforts  across  a  user  story  are  defined  via  story  points,  which  are  the  efforts 
involved  in  both  development  and  testing.  Therefore, during sprint planning estimation across 
user  stories  for  the  testing  efforts  are  provided.  On how to perform test estimation please refer 
to  this  article  about  test  estimation.  Please  note  story  points  across  user  stories  always  follow 
Fibonacci  series  [1,2,3,5,8].  Post  sprint  planning,  work  allocation  across  the  sprint  is designed, 
wherein  the  testers  involved  in  the  project  are  assigned  user  stories  in  the  sprint  for  test  case 
creation and execution 

Implementation and Execution 

The  next  testing  activity  involved  in  Agile  is  the  creation  of  test  cases  across  the  assigned  user 
stories.  Post  creation  of user stories, peer review is performed. This activity provides a two-way 
value  wherein  the  other  QA  gets  awareness  across  the  feature  and  helps  to  provide  inputs  for 
better test coverage. All test cases created in the test management tool must be linked across the 
stories.  This  helps  to  ensure  all  stories  have  the  required  test  cases  across  them.  For  a  better 
quality  of  deliverables,  developers  can  view  the  test  cases  across  the  story  and  ensure  on  an 
overall  basis  that  the  code  handles  the  scenarios  enlisted.  This  helps  to  ensure  a  smaller  cycle 
and  lesser  bugs  across  the  story.  Basically  a  quick  delivery.  Please  note,  as  a  good  plan  rule, all 
test  cases  should  be created when the stories are under development. Once the stories are ready 
for  testing,  only  execution  across  the  story  should  be  the  left  out  task.  This  helps  speed  up  the 
Agile  process.  Creating  test  cases  after  the stories are ready for testing just adds on the time for 
the closure of the story. 

Post  creation  of  test  cases,  once  stories  are  ready  for  testing,  the  test  cases  created  should  be 
executed  across  it.  Another  good  practice  while  execution  is  to  ensure  the  assigned  tester  who 
created  the  test  cases  should  not  be  executing  them.  The  reason  behind  it  is  that  the  person 
would  just  execute  the  test  cases  and  won't  explore  the  further  area  via  ad-hoc  testing,  since 
according  to  him  all  test  cases  across  the  features  have  been  written  and  he  could  not  think 
more  out  of  it.  But  a  person who is executing the test cases may come across more pointers and 
may  perform  ad-hoc  testing,  also.  In  an  Agile  environment,  ad-hoc  testing  plays  an  important 
role  due  to  the  shrinking  testing  cycles  available.  During  execution,  all  testing  types  should  be 
implemented  be  it  functional,  UI,  usability,  cross-browser,  etc.  You  can  refer  article on how to 
ace your execution skills for it. 

All  bugs  encountered  across  stories  should  be  logged  in  the  bug  management  tool  and  linked 
with  user  stories  as  well  as  test  cases.  A  triage  meeting  is  conducted  to  propose  a  plan  for  the 
bugs  logged  and  their  fix.  Post  the  bugs  are  fixed,  they  are  retested  across  the  stories  and 
closed. 

Sprint Closure Activities 

Once  all  the  bugs  linked  to the stories and test cases are retested and closed, the user stories are 

also  closed  and  are  made  ready  for  the  Product  Owner  to  be  accepted.  A  sprint  review  is 
performed  demonstrating  the  deliverables  of  the  sprint.  If  any  story  within  a  sprint  does  not 
gets  closed  due  to  outstanding  bugs  or  development  work  pending,  those  get  overflow  to  the 
next  sprint.  It  is  vital  to  understand  a  story  is  considered  a  deliverable  only  after  testing 
activities  are  closed  and  not  just  with  mere  development  work  completion.  A  defect  analysis 
report  will  be  created  after  every  sprint.  This  report can also be created once the release is over 
rather  than  across  each  sprint  end.  A  sprint  retrospective  meeting  would  be  conducted  to 
discuss  what  went  good,  bad  and  what  should  be  done to ensure better productivity of the next 
sprint. 

Regression 

After  all  the  sprints in a release are complete, regression testing will be performed. A regression 

suite  would  be  created  from  the  test  cases  of  the  features  planned  in  the  release along with the 
impacted  test  cases  of  the  previous  releases.  The  regression  suite  would  be  approved  by  the 
Product  Owner.  Based  on  the  approval,  a  regression  estimate  would  be  prepared  before 
kick-starting regression that would outline the time required to complete off regression. 

Daily  status  emails would be shared with the stakeholders highlighting the execution status and 

the  number  of  bugs  encountered.  Depending  upon  the  number  of  bugs  and  complexity  of 
business  involved,  the  regression may be divided into multiple cycles. Retesting across the bugs 
would  also  be  performed  in  those  cycles.  Post  regression completion a sign-off report would be 
created  and  shared  with  the  stakeholders.  If  required a cumulative defect analysis report for all 
sprints will be also shared along with it. 

Release Activities 

After  a  release  closure,  the  build  is  deployed  to  the  UAT  environment  and  is  made  ready  for  a 
few  users  to  perform  user  acceptance  testing.  After  deploying  the  release  to  UAT,  a  smoke  is 
performed  by  the  alpha  testers  and  after  the  smoke  success,  the  release  is  given  to  the  beta 
testers  who  test  the build before signing off from their end to be shipped to production. Around 
a week time may be provided for beta testers to complete testing. Once testing is completed, the 
build  is  been  deployed  to  production  and  is  made  ready  for  end  users  to  be  tested  after 
performing  a  round  of  smoke  by  the  alpha  testers.  Any  bugs  encountered  during  UAT  or 
production  release  would be logged and provided quick fixes if possible or a point release would 
be planned for the issues raised. 

During  this  time  other  members  of  the  testing  team  would  be  performing  root  cause  analysis 
across the bugs raised in UAT or production. 

Getting Ready for The Next Release 

After  the  release,  the  team  would  prepare  themselves  for  the  next  release, which would involve 
going  through  the  storytellers  encapsulating  the  features  planned  up  for  the  release.  Any 
business clarifications or issues would be raised and cleared during this phase. 

What is an Acceptance Criteria? 

An  acceptance  criterion  is  a  set  of accepted conditions or business rules which the functionality 
or feature should satisfy and meet, in order to be accepted by the Product Owner/Stakeholders. 

This  is  a  very  important  part  of  user  story  completion  and  it  should  be  studied  by  the  Product 
Owner  and  Business  Analyst  very  meticulously  because missing a single criterion can cost a lot. 
This is a simple numbered or bulleted list. 

Its format is as follows: 

“Given some precondition when I do some action then I expect the result”. 

Importance of testing User Story/Acceptance Criteria 

It  is  always  important  to  do  a  deep  dive  in  the  user  stories  and  acceptance  criteria  at  an  early 
stage even before the development or testing commences. Because it involves: 

#1) Wastage of Time: 

If  the  discrepancies  or  mistakes  in  the  user  story/acceptance  criteria  are  found  when 
development  is  going  on  or  testing  is  going  on,  then  a  lot  of rework may need to be done in the 
remaining sprint time. 

It  doesn’t  happen  that  even  if  the  Product  Owner  missed  few  things,  they  will  move  the  user 
story  to  the  coming  sprint.  95%  chances  are  that  they  ask  the  team  to  do  the  necessary 
implementation and release it in the same sprint. 

Hence  it becomes a nightmare for the team as they have to spend extra time, come on weekends 
or  work  late  night.  This  can  be  avoided  by  studying  and  discussing  the  user  story/acceptance 
criteria at the earliest possible stage. 

#2) Wastage of Efforts: 

The  developers  and  QA  have  to  revisit  the  implemented  code  and  test  cases  again.  Updating, 
adding  and  removing  as the per requirement is not an easy task. It becomes too painful as there 
is already a pressure to deliver on time. 

In  such  a  situation,  there  are  chances  of  mistakes  in  the  development  or  testing  stage.  If  you 
come  across  such  situation  go  for  ‘DevQA  Pairing’.  As  an  icing  on  the  cake,  you  may  not  get  a 
compensation for the extra work. 

Acceptance  Criteria  are  a  set  of  statements,  each  with  a  clear  pass/fail  result,  that  specify  both 
functional  (e.g.,  minimal  marketable  functionality)  and  non-functional  (e.g.,  minimal  quality) 
requirements  applicable  at  the  current  stage  of  project  integration.  These  requirements 
represent  “conditions  of  satisfaction.” There is no partial acceptance: either a criterion is met or 
it is not. 

These  criteria  define  the  boundaries  and  parameters  of  a  User  Story/feature  and  determine 
when  a  story  is  completed  and  working  as  expected.  They  add  certainty  to  what  the  team  is 
building. 

Acceptance  Criteria  must  be  expressed  clearly, in simple language the customer would use, just 

like  the  User  Story,  without  ambiguity  as  to  what  the  expected  outcome  is:  what  is  acceptable 
and  what  is  not  acceptable.  They  must  be  testable:  easily  translated  into  one  or  more 
manual/automated test cases. 

Acceptance  Criteria  may  reference  what  is  in  the  project’s  other  User  Stories  or  design 
documents  to  provide  details,  but  should  not  be  a  rehash  of  them.  They  should  be  relatively 
high-level while still providing enough detail to be useful. They should include: 

● Functional  Criteria:  Identify  specific  user  tasks,  functions  or  business  processes  that 
must  be  in  place.  A  functional  criterion  might  be  “A  user  is  able  to  access  a  list  of 
available  reports.”  A  non-functional  criterion  might  be  “Edit  buttons  and  Workflow 
buttons comply with the Site Button Design.” 
● Non-functional  Criteria:  Identify  specific  non-functional  conditions  the 
implementation  must  meet,  such  as  design  elements.  A  non-functional  criterion  might 
be “Edit buttons and Workflow buttons comply with the Site Button Design.” 
● Performance  Criteria:  If  specific  performance  is  critical  to  the  acceptance  of  a  user 
story,  it  should  be  included.  This  is  often  measured  as  a  response  time,  and  should  be 
spelled out as a threshold such as “1-2 seconds for a query response.” 

Acceptance  Criteria  should  state  intent,  but  not  a  solution  (e.g.,  “A  manager  can  approve  or 
disapprove  an  audit  form”  rather  than  “A  manager  can  click  an  ‘Approve/Disapprove’  radio 
button  to  approve  an  audit  form”).  The  criteria  should  be  independent  of  the  implementation: 
ideally the phrasing should be the same regardless of target platform. 

The Three Pillar Way to Agile Test Planning 

Three  Pillar  follows  a  set  of  best  practices  in  Quality  Assurance  Testing  that  proves  its  value 
when  delivering  products  to  our  customers.  Test  planning  is  an  important  milestone  in  the 
development  process  that  needs  to  be  very  carefully  planned.  Here  are five rules to the road for 
test planning in agile that we incorporate in every Three Pillar engagement. 
1. Define a Test Strategy 

While  it  may  not  be possible to identify the scope of items to be tested early, it is possible and in 

fact critical to project success to determine a test strategy. The test strategy should include: 

QA  Build  strategy:  ​Who  is  responsible  for  the QA build? At what points in the sprint will a build 

be delivered to QA? is additional hardware required? 

Test  data  creation:  ​In  the  early  sprints  dependencies  between  components  that  are  still  under 
development may require mocking up of test data. Or later on, in order to perform certain tests, 
such  as  performance  testing,  users  may  need  to  be  loaded  into  the  DB.  The  Test  Plan  needs  to 
identify when Test Data may need to be created and who is responsible for creating it. 

Types  of  testing  and test tools: ​Who is responsible for unit testing? At what point in the product 

lifecycle  will  the  product  be  stable  enough  to  develop  automated  tests?  What  tools  should  be 
used  for  automated  testing?  What  tools  are  to  be  used  for  performance  testing?  Most 
importantly,  the  Test Plan needs to ensure that time and resources are allocated to each of these 
testing types. 

Integration  testing:  How  will  the  interfaces  between  the  product  and  external  systems  be 
tested? What tools will be used to test these interfaces? 

2. Define Scope 

In  an  agile  development  effort,  QA  takes  place  throughout  the  project,  i.e.,  within each sprint. 
Every  sprint,  with  the  possible  exception  of  “sprint  zero”  should  have  demonstrable  code  that 
can  be  tested.  Since  there  are  only  a  few  days  (typically 2-4 days) allocated to QA and bug fixing 
at  the  end  of  a  sprint,  the  Test  Plan  needs  to  clearly  define  the  expectations  in  terms  of  code 
quality  for  the  sprint  demos.  It  should  also  define  the  kinds  of  tests  to  be  run  during  a  sprint. 
Typically,  the  early  sprints  where  a  lot  of  new  functionality  is  being  developed  will  only  have 
time  for  testing  the  “happy  path.”  As  one  gets  to  the  later  sprints,  the  code  matures,  and  more 
time  needs  to  be  allocated  for  automated  testing  and  performance  testing,  as  well  as  negative 
testing.  Depending  on  the overall complexity of the product, 1-2 sprints may need to be devoted 
exclusively  to  testing  and  bug  fixing.  It  is  important  that  the  Test  Plan  tie  in  closely  with  the 
Product Roadmap, which captures the features planned for each sprint. 

3. Be Prepared to Re-Scope Often 

Because  scope  changes  often  during  an  agile  development  project,  the  Test  Plan  needs  to  be  a 
living  document  that  is  updated  to  reflect  changes  in  the  project.  For  example,  a  decision  may 
be  made  to  expose  backend  functionality  using  REST  APIs  to  allow  for  the  creation  of  mobile 
and  desktop  clients.  This  may  not  have  been  in  scope  when  the  Test Plan was created. The Test 
Plan  needs  to  be  updated  to  include  the  different  types  of  tests  required  to  validate  the  REST 
APIs,  such  as  security  tests  to  ensure  only  users  with  the  appropriate  privileges  have  access  to 
certain  information,  performance  tests  to  determine  how  the  system  behaves  under  load,  and 
negative tests to ensure the system can handle invalid data. 

4. Identify Risks and Mitigation Strategies 

It  is  essential  that  the  Test  Plan  identify  risks.  A  feature  may  be  very  complex  and  require 
testing  multiple  execution  paths,  for  example,  and  there  may  be  insufficient  time  allocated  to 
test  the  feature.  A  mitigation  strategy  would  be  to  allocate  more  resources  for  a  short  burst  to 
do  the  testing  or  pick  the  execution  paths  that  are  most  likely  to  be  executed by end customers 
after discussion the risks with the client. 

5. Have an Open and Continuous Feedback Loop 

It  is  critical  that  the  product  be  designed  with  quality  in  mind.  Changes  in  product features or 
addition  of  new  features  impact  the  Test  Plan  and  thereby  product  quality.  Hence the QA Lead 
needs  to  be fully engaged in product decisions with product owners and development leads who 
in  turn  need  to  take  QA  testing  estimates  into  consideration  while  developing/changing  the 
Product Roadmap. 

MODULE 5 

How an Agile team works 

Agile  project  management  was  developed  as  an  alternative  to  traditional  project  management, 
which  is  directed towards a major final deliverable. Agile instead breaks goals down into several 
independent products that can be developed, released, and iterated upon quickly. 

The  two  main  styles  of  Agile  project  management  are  Scrum  and  Kanban,  which  both  utilize  a 
board to visualize tasks in columns of to-do, in progress, and done. 

There are a few defining characteristics of an Agile workflow: 

Daily  standup  –  A  daily  meeting  in  which  contributors  and  managers  discuss  what  work  was 
done yesterday, what they’re working on today, and any questions that come up. 
Sprints  –  Short  spans  in  which  products  are  planned,  developed,  reviewed,  and released. They 
are projects within the projects. 

Regular  reviews  and  retrospectives  –  An  Agile  team  manages  itself,  but  there  are  built-in 
measures  to  make  sure  work  is  being  delivered  at  a  consistent quality. Peer review and reviews 
by managers occur before tasks get completed and after the sprint is over. 

With  short  task  spans  and  demanding  schedules,  an  Agile  workflow  requires  a  coordinated 
team.  Roles  have  to  be  circumscribed  enough  so  that  people  know  what  they ought to be doing 
at all times, yet flexible enough to allow people to take the initiative and exceed expectations. 

A  Scrum  team  is  small,  lean,  and  results-driven.  The  ideal  Scrum  team  is  5-6 people. An Agile 
team working in Scrum has three roles: 

The  Product  Owner – Often an executive or key stakeholder, the Product Owner has a vision for 

the  end  product  and  a  sense  of  how  it  will  fit  into  the  company’s  long-term  goals.  This  person 
will  need  to  direct  communication  efforts,  alerting  the  team  to  major  developments  and 
stepping in to course-correct and implement high-level changes as necessary. 

The  Scrum  Master  –  ​The  Scrum  Master  is  most  akin  to  a  project  manager.  They  are guardians 
of  process,  givers  of  feedback,  and  mentors  to  junior  team  members.  They  oversee  day-to-day 
functions,  maintain  the  Scrum  board,  check  in  with  team  members,  and  make  sure  tasks  are 
being completed on target. 

The  Team  Member  –  Team  members  are  the  makers:  front-  and  back-end  engineers, 
copywriters,  designers,  videographers,  you name it. Team members have varied roles and skills 
but all are responsible for getting stuff done on time and in excellent quality. 

Rapid  application  development  (RAD)  is  an  agile  project  management  strategy  popular  in 
software development. 

The  key  benefit  of  a  RAD  approach is fast project turnaround, making it an attractive choice for 

developers  working  in  a  fast-paced  environment  like  software  development.  This  rapid  pace  is 
made  possible  by  RAD’s  focus  on  minimizing  the  planning  stage  and  maximizing  prototype 
development. 

By  reducing planning time and emphasizing prototype iterations, RAD allows project managers 
and  stakeholders  to  accurately  measure  progress  and  communicate  in  real  time  on  evolving 
issues  or  changes.  This  results  in  greater  efficiency,  faster  development,  and  effective 
communication. 
You can break down the process in a few ways, but in general, RAD follows four main phases. 

Phase 1: Requirements planning 

This  phase  is  equivalent  to  a  project  scoping  meeting.  Although  the  planning  phase  is 
condensed  compared  to  other  project  management  methodologies,  this  is a critical step for the 
ultimate success of the project. 

During  this  stage,  developers,  clients  (software  users),  and  team  members  communicate  to 
determine  the  goals  and  expectations  for  the  project as well as current and potential issues that 
would need to be addressed during the build. 

A basic breakdown of this stage involves: 

● Researching the current problem 

● Defining the requirements for the project 
● Finalizing the requirements with each stakeholder’s approval 

It  is  important  that  everyone  has  the  opportunity  to  evaluate the goals and expectations for the 
project  and  weigh  in.  By  getting  approval  from  each  key  stakeholder  and  developer,  teams can 
avoid miscommunications and costly change orders down the road. 

Phase 2: User design 

Once  the  project  is  scoped  out,  it’s  time  to  jump  right  into  development,  building  out  the  user 
design through various prototype iterations. 

This  is  the  meat  and  potatoes  of  the  RAD  methodology—and  what  sets  it  apart  from  other 
project  management  strategies.  During  this  phase,  clients  work  hand  in  hand  with  developers 
to  ensure  their  needs  are  being  met  at  every  step  in  the  design  process.  It’s  almost  like 
customizable  software  development  where  the  users  can  test  each  prototype  of  the  product,  at 
each stage, to ensure it meets their expectations. 

All  the  bugs  and  kinks  are  worked  out  in  an  iterative  process.  The  developer  designs  a 
prototype,  the  client  (user)  tests  it,  and  then  they  come  together  to  communicate  on  what 
worked and what didn’t. 

This  method  gives  developers  the  opportunity  to  tweak  the  model  as  they  go  until  they  reach  a 
satisfactory design. 
Both  the  software  developers  and  the  clients  learn from the experience to make sure there is no 
potential for something to slip through the cracks. 

Phase 3: Rapid construction 

Phase 3 takes the prototypes and beta systems from the design phase and converts them into the 
working model. 

Because  the  majority  of  the  problems  and  changes  were  addressed  during  the  thorough 
iterative design phase, developers can construct the final working model more quickly than they 
could by following a traditional project management approach. 

The phase breaks down into several smaller steps: 

● Preparation for rapid construction 

● Program and application development 
● Coding 
● Unit, integration, and system testing 

The software development team of programmers, coders, testers, and developers work together 
during  this  stage  to  make  sure  everything  is  working  smoothly  and  that the end result satisfies 
the client’s expectations and objectives. 

This  third  phase  is  important  because  the  client  still  gets  to  give  input throughout the process. 
They can suggest alterations, changes, or even new ideas that can solve problems as they arise. 

Phase 4: Cutover 

This  is  the  implementation  phase  where  the  finished  product  goes  to  launch.  It  includes  data 
conversion, testing, and changeover to the new system, as well as user training. 

All final changes are made while the coders and clients continue to look for bugs in the system. 

Benefits of RAD methodology 

RAD  is  one  of  the  most  successful  software  development  programs  available  today,  with 
numerous benefits for both software development teams as well as their clients. 

Here are just a few advantages: 

● RAD lets you break the project down into smaller, more manageable tasks. 
 ● The  task-oriented  structure  allows  project  managers  to  optimize  their  team’s efficiency 
by assigning tasks according to members’ specialties and experience. 
● Clients get a working product delivered in a shorter time frame. 
● Regular  communication  and  constant  feedback  between  team  members  and 
stakeholders increases the efficiency of the design and build process. 
● With  a  shorter  planning  phase  and  a  focus  on  highly  iterative  design  and  construction, 
RAD  teams  are  able  to  accomplish  more  in  less  time  without  sacrificing  client 
satisfaction. 

Anybody  who  has  a  complex  project  can  benefit  from  using  Scrum.  Prioritize  large  to-do  lists 
into manageable tasks with improved teamwork, better communication, and faster results. 

Scrum  has  streamlined  software  development  —  and  professionals  from  around  the  world  are 
starting  to  see  the  value  of  using  Scrum.  Of  all  the  possible  Agile  frameworks  used  by 
companies, 66 percent are Scrum or Scrum variants. 

Why should you use Scrum? 

Scrum  has  the  power  to  transform  project  management  across  every  industry,  every  business, 
and  even  across  life  in  general.  By  using  Scrum,  you’ll  become  more  Agile,  discovering  how  to 
react  more  quickly  and  respond  more  accurately  to  the  inevitable  change  that comes your way. 
And  by  staying  focused,  collaborating,  and  communicating,  you  can  accomplish  what  truly 
needs to be done — successfully. 

Most  important,  Scrum  is  not  unproven  hype.  It’s a solid and successful Agile framework that’s 

been  applied  to  a  variety  of  projects  and  teams.  Universities  use  Scrum  to  deliver  valued 
projects to clients. Militaries have relied on Scrum to prepare ships for deployment. 

So  whether  you’re  working  on  the  next  smartphone  app,  managing  logistics  for  a  store,  or 
planning  a  charity  event,  you  should  take  a  closer  look at using Scrum. And Scrum Alliance can 
give  you  the  proven  framework,  best  implementation  practices,  and  supportive  guidance  you 
need to achieve success. 

Cynefin Framework 

The  Cynefin  framework  exists  to  help  us  realize  that  all  situations  are  not  created  equal  and to 
help  us  understand that different situations require different responses to successfully navigate 
them. 
You  can  see  in  the  above  diagram  that  there  are  5  domains.  What?  You  only  see  four?  Don’t 
forget the dark mass of Disorder at the center. 

Obvious (formerly known as Simple) is the domain of best practices. 

Characteristics:  Problems  are  well  understood  and  solutions  are  evident.  Solving  problems 
requires  minimal  expertise.  Many  issues  addressed  by  help  desks  fall  into  this  category.  They 
are handled via pre-written scripts. 

Approach:  Problems  here  are  well  known.  The  correct  approach  is  to  sense  the  situation, 
categorize it into a known bucket, and apply a well-known, and potentially scripted, solution. 

Complicated is the domain of good practices. 

Characteristics:  You  have  a  general  idea  of  the  known  unknowns  —  you  likely  know  the 
questions  you  need  to  answer  and  how  to  obtain  the  answers.  Assessing  the  situation  requires 
expert  knowledge  to  determine  the  appropriate  course of action. Given enough time, you could 
reasonably  identify  known  risk  and  devise  a  relatively  accurate  plan.  Expertise  is  required, but 
the work is evolutionary, not revolutionary. 

Approach:  ​Sense  the  problem  and  analyze.  Apply  expert  knowledge  to  assess  the  situation and 
determine a course of action. Execute the plan. 

Complex is the domain of emergent solutions. 

Characteristics:  There  are  unknown  unknowns  —  you  don’t  even  know  the  right  questions  to 
ask.  Even  beginning  to  understand  the  problem  requires experimentation. The final solution is 
only  apparent  once  discovered.  In  hindsight  it  seems  obvious,  but  it  was  not  apparent  at  the 
outset.  No matter how much time you spend in analysis, it is not possible to identify the risks or 
accurately predict the solution or effort required to solve the problem. 

Approach:  Develop  and  experiment  to  gather  more  knowledge.  Execute  and  evaluate.  As  you 
gather  more  knowledge,  determine  your  next  steps.  Repeat  as  necessary,  with  the  goal  of 
moving your problem into the “Complicated” domain. 

Chaotic is the domain of novel solutions. 

Characteristics:  ​As  the  name  implies,  this  is  where  things  get  a  bit  crazy.  Things have gone off 
the  rails  and  the  immediate  priority  is  containment.  Example:  Production  defects.  Your  initial 
focus  is  to  correct  the  problem  and  contain  the  issue.  Your  initial  solution  may not be the best, 
but  as  long  as  it  works,  it’s  good  enough.  Once  you’ve  stopped  the  bleeding,  you  can  take  a 
breath and determine a real solution. 

Approach:  ​Triage.  Once  you  have  a measure of control, assess the situation and determine next 

steps. Take action to remediate or move your problem to another domain. 

Disorder is the space in the middle. 

Characteristics:  If  you  don’t  know  where  you  are,  you’re  in  “Disorder.”  Priority  one  is  to  move 
you to a known domain. 

Approach:  ​Gather  more  info  on  what  you  know  or  identify  what  you  don’t  know.  Get  enough 
info to move to a more defined domain. 

 
Co-location vs. Distributed Teams- WORKING IN DISTRIBUTED TEAMS IN AGILE 

Teams  co-locate  because  it  maximizes  their  ability  to  communicate  in  person.  Working  in  the 
same  room  is  core  to  all  the  Agile methodologies, including scrum. As Ken Schwaber, author of 
The  Enterprise and Scrum, said, “The best communication is face to face, with communications 
occurring  through facial expression, body language, intonation and words. When a white board 
is  thrown  in  and  the  teams  work  out  design  as  a  group,  the  communication  bandwidth 
absolutely sizzles.” 

Given  that  communication  is  such  a  significant  part  of  the  efforts  involved  in  delivering 
software, why then are distributed teams so prevalent? The answer speaks to the reality of doing 
business  today:  a  company’s  need  to  have  a  global  presence,  to  access  global  talent  and  to 
develop outsourced options. 

In  the  2010  State  of  Agile  survey  conducted  by  VersionOne  (which  you  can  download  at 
versionone.com/state_of_agile_development_survey/10/page3.asp),  more  than  half  the  survey 
respondents  said  they  are  currently  using  Agile  with  both  co-located  and  distributed  teams, or 
planning  to  do  so  in  the  future.  Although  co-locating  your  team  is  the  recommended,  optimal 
approach  for  implementing  Agile  processes,  many  teams  are  unable  to  do  so  for  critical 
business  reasons  and  must  learn  to  follow  Agile  principles  and  practices  in  a  distributed 
development. The information in the rest of this article will explain how to do that. 

De-Agile for Distributed Teams 

What  I  mean  by  de-Agile  is  tailoring  Agile  to  fit  your  team  by  taking  out  processes  that  don’t 
make  sense  and  tweaking  those  that  need  to  be  modified  to  suit  your  needs.  In  a  distributed 
team  environment,  de-Agile  is  mostly  about  removing  the sense of being distributed. You need 
to  educate  each  team  member  about  the  additional  communication  responsibilities  required 
when  working  with  remote  team  members  and  emphasize  the  importance  of  being  open  and 
available.  Everyone  on  the  team  needs  to  be  committed  to  making  Agile  work  in  this 
environment,  and  managers  --  including  the  top  tier  --  must  support  the  tools  and  processes 
required. 

If  you  want  your  team  to  adopt  Agile  practices,  you  might  need  to  play  the  roles  of  facilitator 
and  mentor  at  some  point.  The  de-Agile  route  will  inevitably  have  some  rough  spots  as  your 
team figures out both its shared and unique needs. 

Optimize Team Size and Team Mix 

Effective  distributed  Agile  development  is  about  minimizing  the  impact  of  distribution. 
Mainstream  Agile  processes  work  well  for  teams  of  10  to  15  people,  but  what  if  your  team  is 
much  larger?  Paper-based,  face-to-face  strategies  start  to  fall  apart  as  the  team size grows and 
the  team  distribution  begins  to  span  multiple  time  zones.  You  can  still  use  Agile  processes  for 
larger,  distributed  teams.  You  just  have  to  be  willing  to  adjust  your  processes  to accommodate 
the reality of your team’s environment. 

Finding  the  right  mix  of  talent  at  every  location  is  critical  when  the  team  is  distributed.  If  you 
centralize  one  type  of  work  at  one  location,  you  can  lose  opportunities  to  benefit  from  local 
talent.  For  example,  you  might  know  of  an  excellent  developer  you  can’t  hire  because  your 
development  team  is  in  another  country.  Lost  talent  adds  to  your  company’s  total  recruitment 
costs. 

Distributing  your  processes  and  tasks  as  well  as  the  development  work  is  also  key.  In  the 
centralized  model  just  described,  you  also  risk  being  stuck if your company needs to scale up -- 
or  shut  down  --  a  location.  For  example,  having  all  your  developers  in  one  country,  all  your 
projects  managers  in  another  country,  and  all  your  testers  in  yet  another  country  isn’t  the  way 
to  optimize  the  functioning  of  distributed  teams.  This  type  of  setup  often  leads  to 
one-directional  information  flow  and  can  result  in  chaos  and  the  blame  game  if  things  go 
wrong.  You  also  risk  the  continuity  of  particular  functions  if  you  need  to  close  down  one 
location,  say,  the  one  where  all the product managers work. Factors such as domain complexity 
and  technical  complexity  can  also  complicate  recruiting  and  retaining  the  right  set  of  people 
within a distributed team. 

Distribute Work Evenly 

Make  sure  all  team  members  understand  their  role  and  have  fairly  equal  workloads.  In  a 
distributed  team,  if  the  workload is uneven, you may risk the overall project delivery schedule if 
you  ignore  the  imbalance.  Uneven  workloads  can  also  cause  bottlenecks.  You  should  take 
complaints  about  workload  seriously  and  be  ready  to  balance  the  distribution of work carefully 
and quickly. 

Equalizing  workloads  is  difficult,  but  it  is  possible  when  you  do  a  SWAT  **(**Subjective 
Workload  Assessment  Technique)  analysis  with  each  member.  Doing  SWAT  in  a  distributed 
environment  is  even  more  challenging  because  team  members  are  geographically  distributed 
and  SWAT  requires  one-to-one  discussions.  In  one  of  my  previous  roles,  I  worked  with 
distributed  development  teams  in  the  United  States  and  Australia.  I  found  that  most  of  the 
developers  in  Australia  were  writing  readable  code,  with  appropriate comments and unit tests, 
whereas  the  developers  from  the  United States were struggling. When I discussed the situation 
with  each  team  member  one  on  one,  I  discovered  that  the  U.S.  team  was  doing  most  of  the 
work;  the  Australian  team  had  been  assigned  only  a  small  portion  of  work,  which  meant  they 
had much more time to do their work than their U.S. counterparts. 

Maintaining  relatively  even  workloads  across  the  team  is  also  an  important  part of keeping the 
team  rolling.  If  someone is burning out because of an unrealistically high workload, move some 
tasks  to  another  developer  if  possible.  If  someone  doesn’t  have enough work, find ways to keep 
the  person  engaged  with the project. People at both extremes of the workload range usually lose 
focus and eventually become disengaged. 

Also  make  sure  that  the  members  of  remote  team  are  never  treated  like  “helpers”  for  the  team 
members  in  the  “main”  location.  If  remote  team  members  feel  like  hired hands rather than full 
team members, they may have less commitment to the project. 

Set Up Pair Programming 

Pair  programming,  where  two  team  members  sit  side  by  side  and  work  on  the  same  code,  is  a 
challenge  for  distributed  teams.  When  pair  programming  simply  isn’t  possible,  you  need  to 
adapt  the  “side-by-side” part of it so that you can replicate the experience virtually, for example, 
by using a video-conferencing solution such as Skype or LiveMeeting. 

If  this  solution  isn’t  possible,  you  need  to  replace  pair  programming  with  an  equivalent 
practice,  such  as  a  show-and-tell  hour  or  a  daily  developer  scrum.  In  a  show-and-tell  hour, 
every  team  member  demonstrates  (using  screen sharing) his or her work to the entire team and 
receives  feedback.  In  a  daily  developer  scrum,  developers  meet  briefly  to  collaborate  on 
technical  issues  or  approaches.  This practice fosters code sharing and reusability, and it usually 
results in greater team bonding. 

Enforce and Reinforce Agile Practices 

By  definition,  Agile  approaches  rely  on  a  set  of  mutually  supporting  practices.  When  one 
practice  doesn’t  make  sense  for  one  team,  the practice should be either abandoned or replaced. 
With  distributed  teams,  enforcing  and  reinforcing  a  practice  takes  time  and  effort.  Product 
owners  and  scrum  masters  who  push  a  practice  even  when  it’s  clearly  not  working  are  seen  as 
bullish or aggressive. 

In  a  distributed  environment,  best  practices  around  tool  use  play  a  vital  role  in enforcing Agile 
practices.  For  example,  you  can  enforce  code  check-in  comments  by  setting  up  a  Team 
Foundation  Server  check-in  policy,  or  you  can use a centralized bug-tracking tool and mandate 
status  updates  before  the  daily  scrum  call to track the up-to-date status. For the first few weeks 
after  you  establish  procedures  like  this,  you’ll  notice  that  everyone follows the practices. As you 
get  closer  to  release,  people  tend  to  bypass  them.  As  a  scrum  master,  you need to reinforce the 
use  of  these  practices  to  make  sure  the  project  stays  on  track  and  to  make  them  automatic  for 
developers. 

Use Online Tools for Agile Artifacts 

You  can  take  advantage  of  Agile  process  artifacts  (white  boards,  sticky  notes,  and  so  on)  by 
moving  them  from  their  physical  environment  to  an  online  tool.  There  are  tons  of  tools  out 
there.  I  have  used  Microsoft  SharePoint,  Microsoft  Visual  Studio  Team  System  2008/2010  and 
other  online  tools  (even  Google  Docs  and  Live  groups)  to  keep  a  team  project  on  track.  Visual 
Studio  2010  includes  project  templates  for  Agile  and  scrum  you  can  use  to  organize  your  user 
stories,  product  backlog  and  so  on.  It  also  includes  a  number  of  predefined  reports,  such  as 
burn-down  charts  and  overall  status  reports.  In  SharePoint  2007/2010,  you  can  use  lists  to 
manage  your  tasks  or  bugs.  You  can  also  use  a  document  library  to  manage  your  project 
documents. 

Understand Time Differences 

Teams  whose  members  work  in  various  time  zones  face  unique  communication  challenges. 
Even  though  regular  scrums  and overlapping work hours mitigate this problem to some extent, 
part  of  the  work  often  gets  delayed  because  clarification  is  needed  or  something  requires 
reworking  because  one  person’s  changes  affected  the  work  of  others  in  a  different  location  or 
changes  were  not  propagated correctly end to end. Regular reworking like this can impact team 
health;  morale  can  suffer  when  people  are  repeatedly  asked  to  redo  work.  Sometimes  more 
disciplined  developer-to-developer  handshakes  and  end-of-day  status  notes  to  the  entire  team 
are required. 

When  I  say  developer-to-developer  handshakes,  I  mean  that  development  teams  should 

communicate  the  code  check-in  status  and  code  areas  they  have  changed  during  their  work 
hours  that  the  other  side  should  be  aware  of.  They  should  share  issues  such  as  classes  or 
methods  changed,  files  changed  and  if  the  build was successful post check-in. They should also 
mention  if  there  were conflicts in the code and whether they have shelved the code or checked it 
in.  This  way  of  working  calls  for  more  discipline  since  it  has  to  be  a  regular  activity,  and 
developers  tend  to  bypass  this  e-mail  communication,  assuming people already know what has 
changed.  I  have  seen many teams, lose days trying to figure out what changes another team has 
made and jeopardize the delivery timelines. 

In  one  organization  I  worked  in,  everyone exchanged end-of-day notes that contained the code 

check-in  status,  build  status  and  any  known  issues  that  needed  to  be  worked  on  or  ignored 
when the developers in other locales started their day. 

You  can  help  your  team  work  with  those across the world by first making everyone aware of the 

time  zones  team  members  are  working  in.  You  can  use  anything  from  a  physical  map  with 
pushpins  showing  how  the  team  is  distributed,  to  time  zone  utilities  such  as  Microsoft  Time 
Zone, to one of the tools in Microsoft Outlook 2010, such as Time Zone Data Updater. When you 
enable  multiple  calendars  in  Outlook  2010,  you  can  see  the  time  in  other  time  zones.  In 
Windows  7,  you  can  use  multiple  clocks  for  the  same  purpose.  In  e-mail  messages, you should 
note  the  time  zone  you  are  in  or referring to, for example, by including something like, “Would 
it be convenient for you to discuss this tomorrow at 7:00 a.m. EST?” 
Understand Cultural Differences 

Culture  plays  a  vital  role  in  how  we  behave  in  a  given  situation.  During  the  lifecycle  of  a  large, 
distributed  project,  team  members  are  exposed  to  many  different  situations.  Being  aware  of 
cultural  differences  can  help  them  understand  the  deeper  meanings  in  some  of  their 
communications. 

For  example,  people  in  different  cultures  have  different  ideas  about  authority.  In  Western 
countries,  it’s  okay  to  say  “No”  even  if  someone  with  higher  authority  asks  you  to  deliver 
something.  In  many  Indian  and  Asian  cultures,  however,  the appropriate response in the same 
situation would be “Yes” because an authority figure asked the question, even though the person 
responding  knows  he  or  she  won’t  be  able  to  deliver.  In  most  Asian  cultures,  coming  early  or 
late  to  a  meeting  is  not  necessarily  a  bad  thing,  as  it  is  in  the  United  States  or  the  United 
Kingdom. 

In  one  distributed  project  I  worked  on,  I  interacted  with  both  U.S.  and  U.K.  counterparts.  It 
took  me  a  while  to  figure  out  that  the  members  of  the  U.S.  team  were  more direct and open in 
terms  of  communicating  status  and  updates,  and  they  expected  the  same  from  their 
counterparts.  U.K.  team  members  were  more  conservative  and  political  in  their  dealings  with 
their  counterparts,  expecting  others  to  follow  a  more  hierarchical  communication.  Keep  in 
mind  that  these  are  my  personal  experiences  --  yours  may  differ.  Everyone  is  different 
regardless  of  culture,  and  stereotypes  can  be  harmful.  The  key  here  is  to  be  aware  of  potential 
differences.  Many  organizations  offer  culture  awareness  training  to  their  staff. When working 
in distributed teams, such training is well worth the cost. 

Adapt Communication for Remote Teams 

Agile  teams  typically  rely  on  intensive  person-to-person  communication,  both  within  the team 
and  with  the  customer.  Remote  team  members  miss  out  on  these  face-time  encounters,  and 
their  understanding  consequently  suffers.  When  distributed  team  members  are  working 
through a communication channel in which they can’t see the person (or people) they are talking 
with,  they  need  to  be  able  to  convey  their  agreements,  disagreements  and  mood  through  their 
voice, tone, careful listening and general communication. 

Effective  remote  communication  when  the  parties  aren’t  visible  to  each  other  is  difficult, 
requiring  soft  skills  as  well  as  technical  acumen.  Soft  skills  such  as  being  able  to  communicate 
effectively  and  handle  conflicts  and  negotiations  are  essential  to  distributed  teams.  Some 
people  seem  to  be  born  with  these  skills,  while  others  need  to  be  trained  and  to  have 
opportunities  to  hone  their  skills.  Soft  skills  are  becoming  increasingly  important  as  global 
teams  are  becoming  the  norm  in  many  companies.  Many  organizations  offer  soft  skills 
trainings to their staff or recommend online training. 
You  can  enhance  the  audio  communication  abilities  of  your  distributed teams by providing the 
tools  they  need,  whether  instant  messaging,  VOIP,  wikis  or  mobile  phones.  You  can also make 
tools  that  allow  for  virtual  face-to-face  communication  available,  such  as  videoconferencing 
with Microsoft Lync 2010 and Microsoft Lync Server 2010. 

More Issues to Consider 

Arrange  Face-to-Face  Interactions:  Especially  for  larger  projects,  face-to-face  interactions  are 
sometimes  necessary  to  bring  together  key  team  members,  both  to  attain  buy-in  and  to 
facilitate  team  building.  Make  sure  your  budget  allows  for  travel,  and  let  affected  team 
members know about the travelling requirement. 

Plan  Frequent  Demos  and  Retrospectives:  Product  demos  with  a  retrospective  at  the  end 
increase  the  visibility  of  your  project,  convey  its  status  and  provide  instant  feedback  as  well  as 
opportunities  for  process  adjustment.  Involving  your  customers  in  these  demos  (at  the 
appropriate  times)  fosters  a  shared  understanding  of  the  project’s  business  context  and  allows 
the business stakeholders to communicate with the development teams. 

Provide  the  Right  Tools  and  Training:  Teams  often  use  tools  in  a  suboptimal  way  --  and 
distributed  teams  are  no  different.  First,  identify  the tools that are a must. Get consensus from 
your  team  or  consult  forums  such  as  Stackoverflow.com  to  find  out  which  tools  will  be  useful 
for  your  team  on  a  particular  project.  Second,  train  your  team  on  the  tools.  Don’t  expect  team 
members  to  know  everything  about  a  new  tool  without using it, especially if they learned about 
it  from  online  resources.  Allow  them  time  to  use  the  tool  in  a  production  environment  to 
validate their learning. 

Reorganize  Teams  Only  as  a  Last  Resort:  Give  all  team  members  sufficient  time  to  prove  their 
skills  and  commitment  to  the  project.  In a distributed team, communicating and keeping track 
of  everyone’s  progress  is  more  difficult.  Frequent  team  changes  exacerbate  these  issues. 
Constantly  shuffling  teams  or  reorganizing  can  in  many  cases  lead  to  low  confidence,  low 
morale and low productivity. 

Cultivate  Commitment  to  Quality  and  Delivery:  Not  everyone  understands  the  importance  of 
quality  and delivery. Make sure to educate your team members about the level of quality and the 
delivery  requirements  you  expect  for  every  project.  Constantly look for ways to improve quality 
and  to  reward  people  who  demonstrate  an  eye  for  quality  and  are  willing  to  take  ownership  of 
and responsibility for a project end to end. 

Benefits of Agile Development 

Agile  is  a  powerful  tool  for  software  development.  It  not  only  provides  process  and  efficiency 
benefits  to  the  development  team,  but  also  a  number  of  important  business  benefits  to  the 
organization  as  a  whole. Agile helps product teams deal with many of the most common project 
pitfalls  (such  as  cost,  schedule  predictability  and  scope  creep)  in  a  more  controlled manner. By 
reorganizing  and  re-envisioning  the  activities  involved  in  custom  software  development,  Agile 
achieves those same objectives in a leaner and more business-focused way. 

Here are the 8 primary INDUSTRY benefits of an Agile methodology: 

1. Improved Quality 

One  of  the  greatest  benefits  of  an  Agile  framework  is  improved  product  quality.  By  breaking 
down  the  project  into  manageable  units,  the  project  team  can  focus  on  high-quality 
development,  testing,  and  collaboration.  Also,  by  producing  frequent  builds  and  conducting 
testing  and  reviews  during  each  iteration,  quality  is  improved  by  finding  and  fixing  defects 
quickly and identifying expectation mismatches early. 

By  adopting  Agile  software  development  practices,  organizations  can  deliver  solutions on time 
and  with  a  higher  degree  of  client  and  customer  satisfaction.  By  incorporating  the  ability  to 
change,  they  are  better  able  to  incorporate  feedback  from  demos,  usability  testing,  and 
customers into the product. 

2. Focus on Business Value 

Another  one  of  the  primary  benefits  of  Agile  is  an  increased  focus  on  delivering  strategic 
business  value  by  involving  business  stakeholders  in  the  development process. By doing so, the 
team  understands  what’s  most  important  and  can  deliver  the  features  that  provide  the  most 
business value to their organization. 

3. Focus on Users 

Agile development uses user stories with business-focused acceptance criteria to define product 
features.  By  focusing  features  on  the  needs  of  real  users,  each  feature  incrementally  delivers 
value,  not  just  an  IT  component.  This  also  provides  the  opportunity  to  beta  test  software  after 
each  Sprint,  gaining  valuable  feedback  early  in  the  project  and  providing  the  ability  to  make 
changes as needed. 

4. Stakeholder Engagement 

An  Agile  process  provides  multiple  opportunities  for  stakeholder  and  team  engagement  – 
before,  during,  and  after  each  Sprint.  By  involving  the  different  types  of  stakeholders  in  every 
step  of  the  project,  there  is  a  high  degree  of  collaboration  between  teams.  This  provides  more 
opportunities  for  the  team  to  truly  understand  the  business’  vision,  deliver  working  software 
early,  and  frequently  increases  stakeholders’  trust.  Stakeholders  are  encouraged  to  be  more 
deeply  engaged  in  a  project  since  trust  has  been  established  in  the  team’s  ability  to  deliver 
high-quality working software. 

5. Transparency 

Another  benefit  of  Agile  software  development  is  that  it  provides  a  unique  opportunity  for 
clients  or  customers  to  be  involved  throughout  the  project.  This  can  include  prioritizing 
features,  iteration  planning  and  review  sessions,  or  frequent  software  builds  containing  new 
features.  However,  this  also  requires  customers  to  understand  that  they  are  seeing  a  work  in 
progress in exchange for this added benefit of transparency. 

6. Early and Predictable Delivery 

By  using  time-boxed,  fixed  schedule  Sprints  of  1-4  weeks,  new  features  are  delivered  quickly 
and  frequently,  with  a  high  level  of  predictability.  This  also  provides  the opportunity to release 
or beta test the software earlier than planned if there is sufficient business value. 

7. Predictable Costs and Schedule 

Because  each  Sprint  is  a  fixed  duration,  the  cost  is  predictable  and  limited  to  the  amount  of 
work  that  can  be  performed  by  the  team  in  the  fixed-schedule  time  box.  Combined  with  the 
estimates  provided  prior  to  each  Sprint,  the  company  can  more  readily  understand  the 
approximate  cost  of  each  feature,  which  improves  decision  making  about  the  priority  of 
features and the need for additional iterations. 

8. Allows for Change 

Lastly,  a  key  benefit  of  an  Agile  methodology  is  that,  unlike  a  Waterfall  model,  it  allows  for 
change.  While  the team needs to stay focused on delivering an agreed-to subset of the product’s 
features  during  each  iteration,  there  is  an  opportunity  to  constantly  refine  and reprioritize the 
overall  product  backlog.  New  or  changed  backlog  items  can  be  planned  for  the  next  iteration, 
providing the opportunity to introduce changes within a few weeks. 

Challenges of Agile Development 

Although  there  are  many  benefits  of  Agile  software  development,  there  are  also  a  number  of 
common  challenges  that  prevent  many  teams  from  successfully  scaling  Agile  processes  out  to 
the  enterprise  level.  In  Forrester’s  State  of  Agile  2017:  Agile  at  Scale  development  study,  both 
large and small firms cited the following as the top 3 barriers to Agile adoption: 

1. People’s behavioral change: 

Changing  the  way  people  work  is  difficult  —  the  habits  and  culture  of  a  large  development 
organization  are  typically  deeply  ingrained.  People  naturally  resist  change,  and  when 
confronted  with  an  Agile  transformation,  you  may  often  hear  people  say  things like, “that’s the 
way  we’ve  always  done  it  around  here,”  or  “that  won’t  work  here.”  Accepting  change  means 
accepting  the  possibility  that  you  might  not  currently  be  doing  things  the  best  way,  or  even 
worse,  it  may  challenge  a  person’s  long-held  values.  It’s  easy  for  people  to  keep  their  old 
behaviors and processes—unless there is an exceptionally good reason to make a change. 

2. Lack of skilled product owners from the business side: 

The  Business  Requirements  Document  (BRD)  has  been  used  for  decades.  Yes,  it  has  its 
shortcomings,  but  it’s  familiar.  Most  of  the  people  involved  in  requirements  –  primarily 
business  stakeholders  and  Business  Analysts  (BAs)  –  are  new  to  Agile.  They  don’t  understand 
user  stories  and  hesitate  to  give  up  the  BRD  for  something  different  because  they  view  it  as  a 
contract  between  them  and  IT.  How  will  they  be  able  to  control  the  direction  of  development 
without that contract? 

Additionally,  most  Agile  software  development  teams  use  an  ALM  tool,  which  is  where  user 
stories  need  to  end  up  for  decomposition  into  development  tasks.  Most  business  stakeholders 
and  BAs,  on  the  other  hand,  still  use  Microsoft  Word  and  Excel  to  author  requirements.  This 
tool  mismatch  stifles  the  cross-departmental  collaboration  teams  need  to  realize  the  full 
benefits of Agile. 

3. Lack of dedicated cross-functional teams: 

The  language  used  in  the  principles  behind  the  Agile  Manifesto—which  refer  to  the  technical 
members  of  the Agile team as “developers”—has led many to think that only developers, or what 
many  people  think  of  as  ‘coders,’  are  needed  within  an  Agile  team.  However,  the  Manifesto’s 
guidelines  use  the  word  developer  to  mean  “product developer”—any cross-functional role that 
helps the team deliver the product. 

According  to  the  Scrum  Guide,  a  cross-functional  team  is  a  team  that  is  organized  around 
customer  value  stream  mapping  and  must  include all competencies needed to accomplish their 
work  without  depending  on  others  that  are  not  part  of  the  team.  These  teams deliver products 
iteratively  and  incrementally,  maximizing  opportunities  for  feedback  and  ensuring  a 
potentially useful version of working product is always available. 

An Agile Approach to Risk Management 

Whilst  Agile  practitioners  are  often  able  to  state  what  it  is  they  are  working  on  (e.g.,  user 
stories)  and  what  quality  criteria  apply  (e.g.,  definition  of  done),  it  is  telling  that  they  are 
seldom  able  to  articulate  the  impact  their  work  has  on  overall  project  risk  or  how  they  are 
contributing towards its management. 

The  integration  of  established  risk  management  techniques  into  Agile  projects  requires  care  if 
the  value  of  team heterogeneity, efficient feedback loops and lean decision making are not to be 
eroded.  Accordingly,  it becomes necessary to adapt the risk management approach in a manner 
consistent  with  the  preferences  and  principles  enshrined  in  the  Agile  manifesto  rather  than  to 
simply  graft  traditional  risk  practice  on  top  of  an  Agile  process.  Indeed,  experience  indicates 
that  this  is  possible  using  artefacts  already  commonly  found  in  Agile  projects  (e.g.,  product 
backlog or Kanban board). 

The  natural  cadence  of  Agile  projects  suggests  that  risk  identification  and  assessment,  along 
with  the  identification  of  risk  measures,  should  be  incorporated  into  iteration  planning.  In 
product-oriented  methodologies  (e.g.,  Scrum,  XP),  this  corresponds  to  Sprint  planning; 
whereas,  in  project-focused  approaches  (e.g.,  AgilePM),  this  ought  to  occur  at  the start of each 
Timebox  (i.e.,  a  structured  and  fixed  time  period  that commences with initiation and planning 
activities  that  are  followed  by  implementation  work  and  concluded  with  a  review).  Thereafter, 
treatment  and  monitoring  of  risk  can  be  embedded  in  the  everyday  practices  at  the  iteration 
level. 

One  key  difference  between  traditional  and  Agile project risk management is that ownership of 

risk  is  determined by project team members in a manner similar to the allocation of user stories 
(i.e.,  Agile  requirements)  and  related  tasks.  This  transforms  the  traditional  role  of  the  risk 
manager  into  one  that  has  a  more  facilitative  character  that  ensures  attention  to  risk 
management.  Such  functions  can easily be assumed by existing Agile roles (e.g., Scrum Master, 
DSDM Project Manager). 

Risk Identification and Assessment 

Owing  to  the  manner  in  which  risk  and  effect  are  often  confused,  the  identification  of  risk  is 
harder  than  one  would  imagine.6  Consider, for example, a project to migrate a web application 
from  a  physical  to  a  virtual  infrastructure  in  which  the  concern  is  raised  about  whether  or  not 
the  application  will  be  accessible  after  the  migration.  Whilst  many  may  consider  the 
nonavailability  of  the  web  application  to  be  a  project  risk,  it  is,  in  fact,  the  effect  of  an 
unsuccessful  migration.  The  real  risk  resides  in  the  uncertainty  that  gave  rise  to  the 
inaccessibility  of  the  web  application  in  the  first  place  (e.g.,  doubts  about  whether  the 
configuration  of  the  virtual  infrastructure  is  correct  or  if  the web application is addressable via 
the  domain  name  system  [DNS]).  This  confusion  between  risk  and  effect  is  particularly 
pernicious owing to the manner in which it misdirects risk management activities. 

Given  the  subtle  issues  surrounding  the  understanding  of  risk,  one  of  the  best  techniques  for 
Agile  teams  is  based upon the what-why approach (figure 1). This entails a group brainstorming 
session  to  discover  what  might  occur  in a project followed by an analysis of why each event may 
occur.  Whilst  the  former  identifies  effects,  it  is  the latter that is concerned with risk. Indeed, it 
is  not  uncommon  when  discussing  why  an  event  might  occur  to  hear  explicit  statements  of 
uncertainty.  For  example,  in  the  migration  example  cited  previously,  the  inaccessibility  of  the 
web  application  (what)  may  be  analysed  further  to  reveal  numerous  risk  (whys),  such  as  the 
configuration  of  the  virtual  server  or  correctness  of  DNS  entries,  thereby  enabling  the 
identification  of  meaningful  countermeasures.  The  advantage  of  this  approach  lies  in  its 
simplicity,  especially  for  teams  that  may  otherwise  be  unfamiliar  with  specialist  risk 
management  practices  owing  to  the  prevalence  of  more  generalist  skills.  In  addition,  the 
diversity  often  found  in  Agile teams can be considered a strength in the search for possible risk, 
owing  to  the  variety  of  business  and  technical  perspectives.  When  conducting  such  sessions, 
however,  do  not  focus  on  purely  negative  events  (e.g.,  by  asking  what  might  go  wrong),  but 
rather  keep  the  discussion  open  in  order  to  admit possible opportunities that the project might 
exploit. 

In  keeping  with  traditional  practices,  risk  should  be  recorded  in  a  register.  However,  the 
visibility  of  this  artefact  must be maintained at all times and ownership of risk therein assumed 
by  team members in much the same fashion as user stories or other Agile project tasks. This can 
be  achieved  by  keeping  the  register  in  a  place  accessible  to  all  team  members  and  encouraging 
them  to  provide  feedback  as  often  and  as  early  as  possible  (e.g.,  updates,  omissions, 
corrections). 

Risk  assessment  involves  both  the  determination  of  risk  exposure  (where  t-shirt  sizing  often 
suffices, e.g., using small, medium and large to denote magnitude) and the assignment of a risk 
score  (to  be  used  later  during  risk  monitoring)  that  is based on the risk exposure band in which 
a  risk  falls. This score requires consideration of inherent risk and should accommodate not only 
what  is  involved  in  a  requirement  or task, but also how it is to done (e.g., use of risk-mitigating 
Agile  techniques).  Risk  exposure  is  also  central  to  risk  prioritisation  which,  in  turn,  is  an 
indication of the urgency with which learning must take place in order to tackle project risk. 

Risk Treatment 

Risk  assessment  provides  the  input  required  in  order  to  determine  risk  responses  (e.g.,  avoid, 
accept,  exploit).  Whilst  some  risk  may  be  tackled  by  undertaking  specific  activities (referred to 
as  “risk  tasking”  in  Agile  risk  management),  others  require  attention  to  the  manner  in  which 
activities  are  undertaken  (referred  to  as  “risk tagging” in Agile risk management). For example, 
the  presence  of  requirements  risk  when developing a product user interface may encourage the 
team  to  ensure  that  all  such  user  stories  are  performed  using  pair  programming,  an  Agile 
technique  wherein  two  individuals  work  in  tandem.7  Thus,  the  team  identifies  all  affected 
activities and tags them as a reminder of this decision (e.g., perhaps using a double head icon as 
a  visual  cue  to  use  pair  programming  as  illustrated  in  figure  2)  when  they  later  perform  the 
activities during the iteration. 

A  risk-modified  Kanban  board  encourages  the  colour  coding  of  risk-related  tasks  (e.g.,  green 
for  opportunity,  red  for  threat)  to  support  the  visualisation  of  risk. Incidentally, such practices 
can  also  be  extended  to  other  Agile  artefacts,  including  Agile  story  maps  that  describe  the 
relationship  between  epics  and  their  constitute  user  stories  as  illustrated  in  figure  2.  This 
enables  an  excellent  visualisation of the distribution of risk and even enables detection of where 
risk  analysis  may  have  been  deficient  (e.g.,  a  collection  of  user  stories  with no apparent upside 
or downside risk). 

Risk Monitoring 

During  risk  assessment, the scores assigned to measure inherent risk can be used to construct a 

risk  burndown  chart  that  tracks  overall  risk  management  efforts. This device, which resembles 
the  widely  used  story  point  burndown  chart,  also  makes  clear  to  the  team  that  there  exists  an 
iteration  residual  risk  (comprised  of  the  cumulative  residual  risk  of user stories along with risk 
linked  to  transfer  or  sharing  strategies)  that  cannot  be  entirely  eliminated.  Furthermore,  it 
clearly  exhibits  the  dynamics  of  risk  management  in  a  manner  that  might  not  otherwise  have 
been  clear  (e.g.,  the  fact  that  secondary  risk  may  cause  the  chart  to  rise  rather  than  fall).  In  a 
practice  referred  to  as  “risk  walling,”  it  is  recommended  to  co-locate  the  risk  burndown 
alongside  other  risk-related  artefacts  (e.g.,  risk  register,  risk-modified  Kanban  or  user  story 
map) in order to enhance transparency and actively solicit feedback from the team. 

Here  are  six  important  ways  cloud  computing  and  virtualization  enhance  agile  software 
development. 

1. Cloud Computing Provides an Unlimited Number of Testing and Staging Servers. 

When  agile  development  is  used  without  virtualization  or  clouds,  development  teams  are 
limited  to  one  physical  server  per  development,  staging  and  production  server need. However, 
when  virtual  machines  or  cloud  instances  are  used,  development  teams  have  practically  an 
unlimited  number  of  servers  available  to  them.  They  do  not  need  to wait for physical servers to 
become free to begin or continue their work. 

2. It Turns Agile Development Into a Truly Parallel Activity. 

You  may  use  agile  development  but  still  experience  delays  in  provisioning server instances and 
in  installing  necessary  underlying  platforms  such  as  database  software.  Just  as  the 
Commonwealth  Bank reduced the provisioning of an Oracle database from three months to two 
minutes,  agile  development  teams  can  provision  the  servers  they  need  quickly  themselves, 
rather than wait for IT operations to do it for them. 

Although  an  agile  methodology  aims  to  squeeze  all the inefficiencies and delays out of software 

development,  in  practice  it  becomes  a  serial  activity.  Cloud  computing  can  push  it  toward 
becoming  a  more  parallel  activity  than  it  once  was.  This  leads  to  more  efficient, more effective 
and better utilized agile software development teams. 
3. It Encourages Innovation and Experimentation. 

Being able to spawn as many instances as needed enables agile development groups to innovate. 
If  a  feature  or  a  story  looks  interesting,  a  team  can  spawn  a  development  instance  quickly  to 
code  it  and  test  it  out.  There's  no need to wait for the next build or release, as is the case when a 
limited  number  of  physical  servers  are  available.  When  adding  cloud  computing  to  agile 
development, builds are faster and less painful, which encourages experimentation. 

4. It Enhances Continuous Integration and Delivery. 

As  stated,  cloud  instances  and  virtualization  greatly  enhance  continuous  integration  and 
delivery.  Builds  and  automated  tests  take  time.  Agile  development  groups  may  need  to 
subsequently  fix  the  code  for  tests  that  fail  during  the  automated  testing—and  they need to do 
this again and again until the build passes all the tests. 

Having  a  large  number  of  virtual  machines  available  to  the  agile  development  group in its own 
cloud or on the public cloud greatly enhances the speed of continuous integration and delivery. 

5. It Makes More Development Platforms and External Services Available. 

Agile  development  groups  may  need  to  use  a  variety  of  project  management,  issue 
management,  and,  if  continuous  integration  is  used,  automated  testing  environments.  A 
number of these services are available as Software as a Service (SaaS) offerings in the cloud. 

Agile  development  can  use  a  combination  of  virtualization,  private  clouds  and  the public cloud 
at  the  Infrastructure  as  a  Service  (IaaS)  level.  Such  offerings  include  Amazon  Web  Services, 
GoGrid, OpSource and RackSpace Cloud. 

Then  comes  the  use  of Platform as a Service (PaaS) instances such as the Oracle Database Cloud 

Service, the Google App Engine and the Salesforce.com platform force.com, all of which include 
databases and language environments as services. 

Finally,  there  are  a  number of SaaS services that specifically assist agile development, including 

Saleforce.com,  the  Basecamp  project  management  portal  and  TestFlight,  which  provides 
hosted testing automation for Apple iOS devices. 

6. It Eases Code Branching and Merging. 

In  theory,  agile  development  assumes  that  all  features  can  be  broken  down  into  stories  of 
uniform  size  and  slated  for  builds.  In  practice,  agile  projects  may  encounter  features  whose 
development  efforts  last  longer  than  a  build  or  even  a  release.  In  code  refactoring  efforts, 
current  releases  may  need  to  be  enhanced  with  minor  enhancements  and  used  in  production, 
all  while  a  major  redesign  of  code is going on. Code branching is necessary in these cases. Code 
branching  and  merging  involves  juggling  many  versions  of  development  and  staging  builds. 
With  virtualization  and  cloud  computing,  you  can  avoid  buying  or  renting  additional  physical 
servers for these purposes. 

Balancing Agility and Discipline 

One  of  the  reasons  that  agile methods are so popular today is their ability to respond to change. 

As  evidence  of  this  popularity,  Over  pointed  out  that  about  40  percent  of  software  developers 
use  one  or  more  agile  methods,  compared  with  13  percent  that  only  use  traditional  methods, 
according to a 2010 Dr. Dobbs survey on trends among global developers. 

One  reason  that  agile  methods  have  become  so  popular  is  that  the  pace  of  change  is 
accelerating.  Organizations  are  seeking  solutions  that  will  allow  them  to  become  more 
responsive to change. Agile methods provide some key parts of that capability. 

Balance is key for organizations seeking to implement agile methods. While organizations work 
to  improve  agility,  they  must  do  so  in a disciplined way. Discipline is particularly important for 
organizations  like  DoD  acquisition  programs  and  other  federal  agencies  developing  large, 
mission-critical software-reliant systems at scale. 

It's  important  for  organizations  to  understand  what  is  meant  by  agility.  While  several 
definitions  exist,  Agility  is  responding  rapidly  and  efficiently  to  change  with  consistency.  An 
agile  business,  he  told  the  audience,  should  be  able  to  respond  quickly  to  change,  make 
decisions  quickly,  and  respond  quickly  to  customers'  needs  every  single  time,  not  just 
occasionally. 

Improve  engineering  discipline  –  The  agile  principles  and  practices  when  adopted  and 
implemented  properly,  empower  the  team  members  to  manage  and  enhance  the  quality  of 
software  rather  than  just completing the work. The vital component of the high-quality product 
is  always  a  good  and  scalable  design  and  architecture. When an organization goes for adopting 
the  agile  principles  with  a  goal  of  delivering  a  high-quality  product,  they  also  should  embrace 
sound  engineering  discipline.  A  good  design, perfect configuration management, and effective 
testing strategies are crucial to making the best use of agility. 

What Does Agile Look Like 

Many  software  organizations  claim  to  be  agile  because  they  follow  agile  principles,  but  they 
often  lack  an  understanding  of  what it means to be agile. To achieve a greater understanding of 
agile  methods,  organizations  measure  their  agility  and  evaluate  their  success  along  the 
following factors: 

Response  time.  ​Organizations  should  assess  how  quickly  they  respond  to  a  customer's  needs. 
What  sort  of  experiences  are  users  having  with  the  software  they  are  producing  in  terms  of 
response time? 

Efficiency.  Organizations  should  consider  their  ability  to  deliver  software.  Can  they  produce 
projects  with  the  desired  balance  between  cost  and  quality?  Are  processes  performing 
efficiently?  Can  organizations  respond  to  change  quickly  and  efficiently  or do costs balloon out 
of control when changes are made to the content or requirements of the system? 

Consistency.  Does  every  customer  have the same experience? When customers interact with an 

organization,  are  they  always  seeing  the  same  response  time,  the  same  types of efficiency, and 
the same types of behavior on each application? 

Impediments to Agility in Software 

5  impediments  that  he  deemed  critical  for  organizations  to  overcome  when  they  seek  to 
making agile methods work in practice: 

Lack  of  a  ready  backlog,  which  is  the  list  of  features  that  developers  prioritize  to  build  the 
software,  is  a  serious  concern.  The  manifesto  authors  found  that  80  percent  of  teams  had  a 
ready  backlog,  but within that backlog, only 10 percent of items were ready for implementation. 
As a consequence, delays would occur in projects because the backlog was not prepared. 

Lack  of  being  "done"  at  the  end  of  a  sprint  means  that  as  the  project  is  nearing  the  end  of  the 
sprint  and  declaring  the  sprint  completed,  some  work  items  are  being  deferred  or  skipped, 
which  often  causes  delays.  The  most  common  cause  is  a  poorly  implemented  practice  or  a 
deferred  practice.  For  example,  skipping  unit  testing  can  cause  delays  later  in  the  project,  as 
well as increase cost by at least a factor of 2. 

Lack  of  teamwork  surfaces  when  the  team  fails  to  come  together  and  operate  as  a  team  and 
instead  focuses  on  its  individual  needs.  In  this  type  of  setting,  developers  focus  on  their  own 
user  features  or  stories  and  don't  pay  attention  to  what  the  team  is  doing.  They  attend  their 
daily  standups,  but  fail  to  report  problems  that  might  affect  the rest of the project. When team 
gets  to  the  end  of  a  sprint  and  discovers  that  there  is  still  a  lot  of  work  to  do,  therefore,  sprint 
failure and project delay will result. 
Lack  of  good  design  stemming  from  organizational  structures  that  affects  the  kind  of  designs 
that  software  teams  produce.  For  example,  an  inflexible  hierarchical  structure  often  results  in 
inflexible  hierarchical  designs,  which  in  turn  can  yield  code  that  is  brittle  and  hard  to  use, 
excessively expensive, and prone to high failure rates. 

Tolerating  defects  is  an  unfortunate  reality  for  many  teams  as  they  near  the  end  of  a  sprint. 
They  are  out  of  time  and  deferring  defects  to  the  end  of  a  sprint.  Teams  in  this  situation often 
take  a  set  of  unit  tests  or  other  issues  and defer them to later sprints. When issues are deferred 
(which  is  a  form  of  technical  debt,  as  discussed  by  Ipek  Ozkaya  in  her  Agile  Research  Forum 
presentation),  the  result  is  increased  in  cost  and  higher  failure  rates  later  in  the  lifecycle 
because the defects aren't being addressed as they are discovered. 

Avoiding the Impediments by Balancing Agility and Discipline 

five  principles  that  help  address  impediments  identified  by  the  Agile  community  in  their 
retrospective: 

Build  high-performance  teams.  Software  is  knowledge  work.  Build  self-managed  teams  that 
make their own plans, negotiate their commitments, and know the project status precisely. 

Plan  every  project.  ​Never  make  a  commitment  without  a  plan.  Use  historical  data.  If  the  plan 
doesn't fit the work, fix the plan. Change is not free. 

Use  a  measured  process  to  track  progress.  ​To  measure  the  work,  define  its  measures.  To 
measure  the  process,  define  its  steps.  If  the  process  doesn't  fit  the  work,  fix  the  process. 
Tracking  progress  via  a  measured  process  need  not  require  a  complicated  solution  given  the 
appropriate set of tools and a codified method for applying the tools effectively. 

Design  before  you  implement.  ​Design  is  critical  since  it informs the software implementation. 

Good  designs  produce  less  code  and  simplify  the  downstream  evolution  of  the  code.  Design 
what  you  know  and  explore  the  rest.  When  you  know  enough,  finish  the  design  and  then 
implement  it.  To  be  clear, this principle isn't espousing "big upfront design" (BUFD). It is BUFD 
without the BUF, or just D. Produce enough design to build the implementation. If the design is 
still  too  challenging,  explore  the  problem  first  via  prototyping  to  reduce  design  risk.  Applying 
this  principle  effectively  depends  on  various  factors,  including  the  size  and  complexity  of  the 
application, as well as familiarity with the problem, domain, methods, and tools. 

Make  quality  software  the  top  priority.  ​Defects  are  inevitable.  Poor  quality  wastes  resources. 
The  sooner  a  developer  fixes  a  problem,  the  better.  As  Jeff  Sutherland  stated  in  his 
retrospective,  tolerating  defects,  ignoring  pair  programming  or  code  review  practices,  and 
inadequate  unit  testing  will  substantially  reduce  team  velocity.  Continuous  integration  tools 
and  automated  testing  are  also  important, but testing alone is insufficient because poor quality 
software  will  always  cost  more  to  produce  because  finding  and  fixing  defects  is still expensive, 
and the longer you wait to fix them the greater the cost of repair. 

Rangle  has  relied  on  Agile  development  practices  since  its  foundation  in  2013.  Our  work  with 
over  100  client  organizations  has led us to identify the most prominent focus areas to accelerate 
delivery  of  business  value,  make  applications  easier  to  adapt  to  changing  circumstances,  and 
reduce wasted time and effort. 

MODULE 6  

What is JIRA? 

JIRA  is  a  tool  developed  by  Australian  Company  Atlassian.  It  is  used  for  bug  tracking,  issue 
tracking,  and  project  management.  The  name  "JIRA"  is  actually  inherited  from  the  Japanese 
word "Gojira" which means "Godzilla". 

The  basic  use  of  this tool is to track issues and bugs related to your software and Mobile apps. It 

is  also used for project management. The JIRA dashboard consists of many useful functions and 
features which make handling of issues easy. Some of the key features are listed below.  

JIRA Scheme 

Inside JIRA scheme, everything can be configured, and it consists of 

● Workflows  
● Issue Types 
● Custom Fields 
● Screens 
● Field Configuration 
● Notification 
● Permissions 
JIRA Issues and Issue types 

This section will guide you through JIRA Issue and its types.   

What is JIRA Issue? 

JIRA  issue  would  track  bug  or  issue  that  underlies  the  project.  Once  you have imported project 
then you can create issues.   

Under Issues, you will find other useful features like 

● Issue Types 
● Workflow's 
● Screens 
● Fields 
● Issue Attributes 

Let see JIRA Issue in detail 

Issue Types 

Issue  Type  displays  all  types  of  items  that  can  be  created  and  tracked  via  JIRA.  JIRA  Issues  are 
classified under various forms like new feature, sub-task, bug, etc. as shown in the screen shot. 

There are two types of Issue types schemes in JIRA, one is 

● Default  Issue  Type  Scheme:  In  default  issue  type scheme all newly created issues will be 

added automatically to this scheme 
● Agile  Scrum  Issue Type Scheme: Issues and project associated with Agile Scrum will use 
this scheme 

Overall,  virtualization  and  cloud  computing  remove  the  dependencies  of  test and development 
servers  on  physical  servers,  whether  they  are  virtual  machines  with  just  an  operating  system 
installed  or  fully  configured servers with platforms such as database software, language or code 
libraries.  Virtualization  and  cloud  computing  also  become  indispensable  if  agile  teams  intend 
to  practice  continuous  integration  and  delivery  methods.  This  moves  agile  development  more 
toward  a  parallel  activity,  rather  than  a  serial  one,  by eliminating the delays in provisioning. In 
turn,enterprises can better align innovative development projects with business goals. 
Below  we  present  five  case  studies  that  demonstrate  just  that  -  that  scaling  Agile  is  not  only 
possible,  but  can  also  yield  great  benefits.  We  hope  you’ll  learn  something  new  from  these 
examples! 

1. LEGO 

Agile framework used: Scaled Agile Framework (SAFe) 

Year started: 2015  

LEGO  began  its  journey  to  agility  by  introducing  changes  at  the  team  level.  There  were  20 
product  teams  working  at  the  organization  at  the  time.  At  first,  just 5 teams were transformed 
into  self-organizing  Scrum  teams.  Then,  bit  by  bit,  the  remaining  15  teams  followed  in  their 
footsteps. 

The  result  of  that  initial  change  was  that although individual teams had become Agile, they still 

couldn’t  cooperate  effectively  together.  To  make  that  happen,  LEGO  followed  the  SAFe 
framework pattern and added another level of abstraction - the program level.  

At  the  program  level,  you’ve  got  a  team  of  teams  (also  known as Agile Release Train, or ART for 
short).  At  LEGO,  the  team of teams was meeting every 8 weeks for a big room planning session, 
which  lasted  for one and a half days. During this meeting, teams showcased their work, worked 
out the dependencies, estimated risks, and planned for the next release period.  

There’s  also  the  portfolio  level,  which  is  the  top  layer  of  the  system.  This  is  where  you’ve  got 
long-term  business  plans,  stakeholders,  and  top  management.  Such  division  into 
organizational levels is typical for the SAFe framework.  

Results 

Once  you’ve  empowered  developers  to  manage  their  own  work,  say  goodbye  to  the  army  of 
“managers  with  spreadsheets.”  You  can  stop  doing  excessive  documentation  and  other 
unproductive practices. 

Developers  now  give  more  accurate  estimates,  and  the  outcomes  have  become  more 
predictable.  Previously,  the  person  who  shouted  the  loudest  could  get  their  work  done  faster. 
Now, with visibility taken to the extreme, decisions are based on real necessity.  

Nothing  beats  face-to-face  communication  and  the  positive  effect  it  has  on  team  morale. 
Especially the communication that occurs during LEGO’s big room events. 
LEGO scaling agile study 

Visual,  almost  gamified  planning  helps  focus,  makes  things  obvious  and  easier  to  resolve. 
Giving people independence also makes them more motivated, and they do better work.  

2. Cisco 

Agile framework used: Scaled Agile Framework (SAFe) 

Year started: 2015 

This  case  study  has  been  written  by  Cisco’s  Ashish  Pandey.  Please  note  that  it  concerns  a 
specific Cisco product - the Subscription Billing Platform. 

The  project  used  to  follow  the  Waterfall  methodology.  Cisco  used  to  have separate focus teams 
responsible  for  design,  build,  test,  and  deploy.  Defects  were  many,  and  deadlines  were  being 
frequently missed. People were working overtime. 

Once they switched to SAFe in 2015, here’s what happened. 

Cisco created three ARTs* (Agile Release Trains) for:  

● - Capabilities 
● - Defects/fixes 
● - Projects 

*In the SAFe framework, an ART (Agile Release Train) is essentially a team of teams. 

Cisco journey to agility 

Every  day,  the  team  had  a  15-minute  meeting  to  determine  work  items.  With  SAFe,  they 
attained  greater  transparency:  each  team  knew  what  the  other  teams  were  doing  and  teams 
were able to manage themselves, promoting accountability through status updates/awareness. 

They  also  combined  it  with  the  Scrum  framework  that was being used on another product - the 

WebEx  app  for  Samsung.  Some  XP  practices,  such  as test-driven development and continuous 
integration  (CI),  were  used,  too.  The  conclusion  is  that  you  can  use  one  framework  for  one 
product and another Agile framework for another one within the same organization. 

Results 
Once  Cisco  started  following  the  SAFe  methodology,  started  to  release  often,  and  introduced 
Continuous Integration (CI), they got: 

● A 40% decrease in critical and major defects. 

● A 16% decrease in DRR (Defect Rejected Ratio). 
● A  14%  improvement  in  DRE  (Defect  Removal  Efficiency)  -  thanks  to  CI  and  more 
interaction between international teams.  
● There is no more overtime, and the product increment is delivered on time. 

3. Agile Delivery at British Telecom 

Agile framework used: Scrum + XP; 90-day delivery cycles 

Year started: 2004 

This  is  a  case  study  by  Ian Evans of British Telecom that talks about the company’s transition to 

Agile.  In  2004,  a  new  CIO  arrived  at  British  Telecom  and  decided  to  change  the  Waterfall 
process. The old model was causing a number of issues: 

● -  Too  many  people  were  generating  requirements;  almost  all  requirements  had  a  high 
priority;  attempts  were  made  to  squeeze  a  maximum  number  of  work  items  into  the 
next release. 
● -  There  were  too  many  intermediaries  during  the  design  stage  and  a  painful  approval 
process. 
● -  Development  deadlines  were  hard  to  meet;  there  was  a  lot  of  pressure  on  the 
developers and little time for QA. 
● -  Deployment  was  a  nightmare.  Some  releases  or  even  entire  programs  were  discarded 
as being “too late to the party,” being no longer economically viable or too buggy. 
● To  solve these problems, British Telecom decided to adopt an Agile approach to software 
development and switch to shorter release cycles: 
● -  Instead  of  documenting  all  requirements  up-front,  they  decided  do  user  stories  and 
continuous delivery. 
● -  Customers  should  be directly involved to facilitate approvals and ensure everyone is on 
the same page. 
● -  They  started doing smaller, more frequent iterations to improve quality and have more 
time for integrating increments into the whole. 

British Telecom scaling Agile 

Results 

● When  two  years  passed  since  the  transformation,  no  one at British Telecom was willing 

to go back to the old Waterfall model. These were some of the achievements: 
 ● The  delivery  cycle  went  from  12  months  to  90  days.  It  now  starts  with  a  three-day 
company-wide meeting, at which shareholders are also present. 
● Everyone  involved  has  agreed  to  set  strict  priorities  and  focus  only  on  stories that drive 
business value. 
● At  the  end  of  each  cycle,  the  program  is  evaluated  against  a  set  of success markers. The 
team may be paid a bonus depending on the results. 
● Doing things the Agile way has improved developer morale and motivation.