The document discusses Agile project management using SCRUM methodology. It describes how SCRUM ensures control at each stage and transparency through close cooperation with the customer. Product requirements are prioritized in a backlog and developed iteratively in sprints. User stories are estimated and tracked in a burndown chart to monitor progress. Continuous integration and approval criteria ensure quality control at each stage. The customer assigns a product owner for communication and decision making to enable agile working.

1.  Kliknij, aby edytować styl wzorca podtytułu
vContact: | www.gtFace.com | info@gtFace.com | (+353) 851 261 081
Agile Process

2. Because we are interested only in the success of the customer. SCRUM ensures
control at each stage of the works, full transparency of the project and close
cooperation with the customer. We know that the requirements defined in
contracts often prove inadequate or unnecessary: we are not afraid of changing
them. We are interested in a product that meets the customer’s requirements,
which is not always the same as “compliant with the documentation”. Agile
approach is the success of our customer. The success of our customer is also our
success.
Why we choose SCRUM.

3. The “big picture” is a multi-level presentation of the
requirements towards the system that is to be created.
This is the foundation of our understanding of:
who will use it and what for,
whether it will communicate with other systems and, if yes,
with which ones,
what are the most important business needs that the
system will satisfy.
The general presentation of the system has a significant
impact on the posterior selection of the most important
features and their assessment.
An example of a requirement phrased as a User Story:
Asthe owner of a bank account
The project pricing is carried out by determining the level of
complexity of individual requirements. Our evaluation of
particular stories is based on the knowledge and experience
gained at previous projects. Thanks to this experience, we are
able to compare the requirements and define which are more
and which are less complex. The history of team work indicates
how much time we have to dedicate to implement individual
stories, and after summing up the points, to implement the
entire project. How do we do that? We estimate the degree of
complexity of User Stories:
From the entire Product Backlog, we choose the least and the
most complex story and several intermediate ones and we
discuss them with the customer in detail. Those stories are
the reference point for the other requirements.
The complexity of each story is estimated by the team based
on the values of Fibonacci numbers.
The sum of points from the stories and the average number of
points implemented by the team in the sprint determine the
date of project completion.
The final stage – the pricing„Big picture” in order to achieve
something
As whom
I want to do
something
in order to be able to withdraw money when
the bank is closed
I want to withdraw money from the ATM
User Stories should also contain Approval Criteria, i.e. a
set of requirements whose completion allows both the
team and the customer to be sure that a given user story
has been implemented. For the initial pricing, general
criteria are enough, for example:
entering of the correct PIN code authorises the user;
entering of the incorrect PIN code causes display of a
message on an unsuccessful attempt;
after 3 unsuccessful attempts, the card is blocked by
the ATM.
Product Backlog is a set of business requirements
arranged by priorities On the top, there are features
without which the system cannot function, i.e. those that
meet the most important business needs.
Product Backlog elements most often take the form of
User Stories. These are requirements phased as below:
Product Backlog
What do we need to price a project?

4. How do we organise work in a project?
The team delivers and presents the functional
software after each iteration (the so-called
sprint). Presentation of the performed work
takes place in a test environment. It is always a
functional application, which allows for on-
going control of work progress and the
possibility to verify the requirements defined at
the beginning of the project.
Each sprint is a cycle of events taking place
sequentially:
Planning
choosing User Stories for the next sprint
from the Product Backlog;
setting the goal of the sprint;
accepting the scope by the Team and the
Product Owner.
Daily Scrum Meeting
an everyday 15-minute meeting to
organise the entire day of work and
indicate the blockers;
full control, eliminating blockers;
self-organisation;
Grooming
refinement of the requirements;
joint development of the Approval
Criteria.
Review
presentation of the features implemented in a functional
application;
the customer continuously sees the progress;
we can make and react to comments on an on-going basis;
formal approval of the work performed;
Retrospective
after each sprint, we indicate how to improve the process and
effectiveness of the team;
we identify and eliminate our weaknesses;
resolutions in a visible place – we control each other;
the customer actively participates in the meeting; full
transparency of the team.

5. Our method requires full control at each stage of the works. To ensure this, the
customer has to assign the Product Owner.
The Product Owner should be a person with an authority to make decisions so as
to be able to answer the questions of the team within the shortest possible time.
It is recommended that the Product Owner works in the same location as the
Team. This ensures high level of communication, which is the basis of the agile
approach to work. On the other hand, when carrying out the works, the team
need to have quick answers to their questions guaranteed.
What do we need from
the customer?

6. Quality!
v
Definition of Done (DoD) is the common criteria of
application quality developed by the team and the
Product Owner. DoD is defined for each sprint and
defines when the requirements are met apart from the
Approval Criteria.
Definition of Done
They indicate the detailed conditions and requirements that
have to be met by a feature to be considered implemented.
The Approval Criteria are verified at several stages:
Only those user stories that are not linked to any errors,
Approval Criteria or DOD are considered implemented. Only
then we do state the application is functional.
Approval Criteria DONE means DONE !
coding tests review

7. How we know we will
make it on time.
Burndown Chart for sprints
The progress of works in a sprint is represented on a chart of implemented stories. Each story
has a certain amount of points assigned to it; those points indicate its level of complexity.
By implementing the story, the team “burns down” the points assigned to it. The chart is
updated live and is available to all the persons assigned to the project.
Burndown Chart for the project
The progress of works in a project can be represented by the chart of “burnt down” points. When
the sprint is over, it means that a certain amount of points has been burnt down, based on which
we make a simulation of the project progression. Using historical data, we are able to foresee
various scenarios for the project and promptly react to any possible deviations from the scenario
that ensures success.

8. for your attentionThank you
vContact: | www.gtFace.com | info@gtFace.com | (+353) 851 261 081