Why did we choose SCRUM?

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 coope-

ration with the customer. We know that the requirements deザned in contracts often prove inadequate or unnecessary: we are not afraid of changing them. We are intere-

sted 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.

„Big picture”

Product Backlog

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 signiザcant impact on the posterior selection of the most important features and their assessment.

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 impor-tant business needs.

Product Backlog elements most often take the form of User Stories. These are require-ments phased as below:

As whom I want to do something in order to achieve something

An example of a requirement phrased as a User Story:

The ザnal stage ｼ the pricing

User Stories should also contain Approval Criteria, i.e. a set of requirements whose com-pletion 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.

The project pricing is carried out by determining the level of complexity of individual requ-irements. 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 require-ments and deザne 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.

As the owner of a bank account I want to withdraw money from the ATM

in order to be able to withdraw money when the bank is closed

What do we need to price a project?

Grooming

Review

Retrospective

reザnement of the requirements;

joint development of the Approval Criteria.

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.

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;

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 deザned at the beginning of the project.

Each sprint is a cycle of events taking place sequentially:

Planning

Daily Scrum Meeting

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.

an everyday 15-minute meeting to organise the entire day of work and indicate the blockers;

full control, eliminating blockers;

self-organisation;

Product Backlog Sprint Backlog

1-4 weeks

Daily Scrum Meeting

Functional

software

What do we need from the customer?

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.

Quality!

Deザnition of Done

Approval Criteria

DONE means DONE ρ

Deザnition of Done (DoD) is the common criteria of application quality developed by the team and the Product Owner. DoD is deザned for each sprint and deザnes when the require-ments are met apart from the Approval Criteria.

They indicate the detailed conditions and requirements that have to be met by a feature to be considered implemented. The Approval Criteria are veriザed at several stages:

coding,

tests,

review.

Only those user stories that are not linked to any errors, Approval Criteria or DOD are consi-dered implemented. Only then do we state that the application that we present is functional.

How do we know we will make it on time?

Burndown Chart dla sprintu

Burndown Chart for the project

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 comple-xity. 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.

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, ba-sed 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 devia-tions from the scenario that ensures success.

Transparency of works

We are transparent We believe that only full transparency and early solution of pro-

blems and blockers in a project makes it possible to achieve the ザnal success. All we do can be found in a╁visible place that ensures access for each interested person.

Sprint table

Burndown chart of the sprint is available to everyone. Burndown chart of the project is available for everyone.

The dashboard of the project available for everyone. The dashboard includes:

the sprint process;

the number of open errors;

the ratio of new to performed tasks; the last activity in the tasks;

how many times the story has been corrected.